Open nilaykumardeveloper opened 9 months ago
Hi @nilaykumardeveloper. Thank you for your report. To speed up processing of this issue, make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, Add a comment to the issue:
@magento give me 2.4-develop instance
- upcoming 2.4.x release@magento I am working on this
Join Magento Community Engineering Slack and ask your questions in #github channel. :warning: According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting. :clock10: You can find the schedule on the Magento Community Calendar page. :telephone_receiver: The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, join the Community Contributions Triage session to discuss the appropriate ticket.
Hi @engcom-Bravo. Thank you for working on this issue. In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:
Area: XXXXX
label to the ticket, indicating the functional areas it may be related to.2.4-develop
branch@magento give me 2.4-develop instance
to deploy test instance on Magento infrastructure. 2.4-develop
branch, please, add the label Reproduced on 2.4.x
.Issue: Confirmed
once verification is complete. @magento give me 2.4-develop instance
Hi @engcom-Bravo. Thank you for your request. I'm working on Magento instance for you.
Hi @engcom-Bravo, here is your Magento Instance: https://c323692eebc28d54fed624e12837ba86.instances-prod.magento-community.engineering Admin access: https://c323692eebc28d54fed624e12837ba86.instances-prod.magento-community.engineering/admin_d39d Login: be9e885b Password: c0b1b58ee690
Hi @nilaykumardeveloper,
Thank you for reporting and collaboration.
Verified the issue on Magento 2.4-develop instance and the issue is reproducible.Kindly refer the attached screenshots.
We have given access for all the resources still we are getting the error.
Hence Confirming the issue.
Thanks.
:white_check_mark: Jira issue https://jira.corp.adobe.com/browse/AC-10997 is successfully created for this GitHub issue.
:white_check_mark: Confirmed by @engcom-Bravo. Thank you for verifying the issue.
Issue Available: @engcom-Bravo, You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself.
Sure! If anyone has any suggestions, please let me know. Your input would be greatly appreciated.
Related issue: https://github.com/magento/magento2/issues/36811
HI Guys
just wondering if theres any time estimation on this?
Kind Regards, Joe
need a fix on this too
@engcom-Bravo - has there been any internal development on this issue, is there a workaround? It has completely broken integration with Magento for me, it's a really major bug.
Looks like issue is related to when your storefront URL is not same as your base url at "All Stores View". For me it is still actual for 2.4.6-p4 EE
Looks like issue is related to when your storefront URL is not same as your base url at "All Stores View". For me it is still actual for 2.4.6-p4 EE
Same for me on 2.4.5-p8 CE. Base URL is fine but storefront URL throws the error.
There is not a solution? WIth magento 2.4.7 and 2.4.6 same error. Is really important bug.
Looks like issue is related to when your storefront URL is not same as your base url at "All Stores View". For me it is still actual for 2.4.6-p4 EE
This occurs for all store URLs for me.
There is not a solution? WIth magento 2.4.7 and 2.4.6 same error. Is really important bug.
Seems insane that this major bug isn't being addressed. This is an open issue, P2 priority, confirmed, reproduced and sitting in high priority backlog for nearly half a year.
As a workaround, I hack vendor/magento/module-webapi/Controller/Rest/RequestValidator.php, and add an extra validator:
$headers = $this->request->getHeaders()->toString();
if (str_contains($headers, 'changethispasswordtoarandomsetofsquiggles')) {
return;
}
And then when I make a REST call, I add an extra header in the call:
res = requests.get(
url+"?"+urlparam, verify=self._verify_ssl,
headers={
'Authorization': 'Bearer %s' % self._token,
'TempAuth': 'changethispasswordtoarandomsetofsquiggles',
})
Obviously this isn't ideal as it's a reusable symmetric cleartext password and bypasses finegrained ACL, but at least it works for now..
Any update on this?
The only workaround I now see is the following. If you use the option 'Allow OAuth Access Tokens to be used as standalone Bearer tokens'. And you trust the integration party. You can bypass the (false negative) exception. I would ask the third party for their IP's and do the following:
Inside module-webapi/Controller/Rest/RequestValidator.php change 'checkPermissions()' and add a custom function:
/**
* Perform authentication and authorization.
*
* @return void
* @throws \Magento\Framework\Exception\AuthorizationException
*/
private function checkPermissions()
{
$route = $this->router->match($this->request);
if (!$this->authorization->isAllowed($route->getAclResources())) {
//CUSTOM
if ($this->isFullyTrustedToken()) {
return;
}
$params = ['resources' => implode(', ', $route->getAclResources())];
throw new AuthorizationException(
__("The consumer isn't authorized to access %resources.", $params)
);
}
}
/**
* CUSTOM
*
* @return bool
*/
private function isFullyTrustedToken()
{
$trustedTokens = [
'token1' => ['ip1', 'ip2'], //integration 1
'token2' => ['ip1', 'ip3'] //integration 2
];
//See module-webapi/Model/Authorization/TokenUserContext processRequest()
$authorizationHeaderValue = $this->request->getHeader('Authorization');
if (!$authorizationHeaderValue) {
return false;
}
$headerPieces = explode(" ", $authorizationHeaderValue);
if (count($headerPieces) !== 2) {
return false;
}
$tokenType = strtolower($headerPieces[0]);
if ($tokenType !== 'bearer') {
return false;
}
$bearerToken = $headerPieces[1];
//See framework/HTTP/PhpEnvironment/Request.php getClientIp()
$clientIp = $this->request->getClientIp();
// Check if token exists and IP is allowed for that token
if (isset($trustedTokens[$bearerToken]) && in_array($clientIp, $trustedTokens[$bearerToken])) {
return true;
}
return false;
}
Needless to say; be careful. I do not have tested this a lot. Use at your own risk.
Summary
In the testing environment, it gives below errors,
}
Its already Yes in: Allow OAuth Access Tokens.
I tried it in PHP script with Integration user as well as bearer token and not working in both scenario. The main thing is that live and local environment looks fine with same code file and DB setup.
So my concern is that, Is any configuration on server can impact on this?
PHP script:
function sign($method, $url, $data, $consumerSecret, $tokenSecret)
{
$url = urlEncodeAsZend($url);
$data = urlEncodeAsZend(http_build_query($data, '', '&'));
$data = implode('&', [$method, $url, $data]);
$secret = implode('&', [$consumerSecret, $tokenSecret]);
return base64_encode(hash_hmac('sha256', $data, $secret, true));
}
function urlEncodeAsZend($value)
{
$encoded = rawurlencode($value);
$encoded = str_replace('%7E', '~', $encoded);
return $encoded;
}
// REPLACE WITH YOUR ACTUAL DATA OBTAINED WHILE CREATING NEW INTEGRATION
$consumerKey = 'XXXXXXXXXXXXXXXXXXXXXXXXXXX'; $consumerSecret = 'XXXXXXXXXXXXXXXXXXXXXXXXXXX'; $accessToken = 'XXXXXXXXXXXXXXXXXXXXXXXXXXX'; $accessTokenSecret = 'XXXXXXXXXXXXXXXXXXXXXXXXXXX'; $method = 'GET';
$url = 'http://xxxx.staging.com/rest/V1/orders/38024';
$data = [
';'oauth_consumer_key' => $consumerKey,
'oauth_nonce' => md5(uniqid(rand(), true)),
'oauth_signature_method' => 'HMAC-SHA256',
'oauth_timestamp' => time(),
'oauth_token' => $accessToken,
'oauth_version' => '1.0',
];
$data['oauth_signature'] = sign($method, $url, $data, $consumerSecret, $accessTokenSecret);
//print_r($data); $curl = curl_init();
curl_setopt_array($curl, [
CURLOPT_RETURNTRANSFER => 1,
CURLOPT_URL => $url,
CURLOPT_HTTPHEADER => [
'Authorization: OAuth ' . http_build_query($data, '', ',')
]
]);
$result = curl_exec($curl); $orderData = json_decode($result,true); curl_close($curl);
echo '
?> POSTMAN:
Examples
` <?php
function sign($method, $url, $data, $consumerSecret, $tokenSecret)
{
$url = urlEncodeAsZend($url);
$data = urlEncodeAsZend(http_build_query($data, '', '&'));
$data = implode('&', [$method, $url, $data]);
$secret = implode('&', [$consumerSecret, $tokenSecret]);
return base64_encode(hash_hmac('sha256', $data, $secret, true));
}
function urlEncodeAsZend($value)
{
$encoded = rawurlencode($value);
$encoded = str_replace('%7E', '~', $encoded);
return $encoded;
}
// REPLACE WITH YOUR ACTUAL DATA OBTAINED WHILE CREATING NEW INTEGRATION
$consumerKey = 'XXXXXXXXXXXXXXXXXXXXXXXXXXX'; $consumerSecret = 'XXXXXXXXXXXXXXXXXXXXXXXXXXX'; $accessToken = 'XXXXXXXXXXXXXXXXXXXXXXXXXXX'; $accessTokenSecret = 'XXXXXXXXXXXXXXXXXXXXXXXXXXX'; $method = 'GET';
$url = 'http://xxxx.staging.com/rest/V1/orders/38024';
$data = [
';'oauth_consumer_key' => $consumerKey,
'oauth_nonce' => md5(uniqid(rand(), true)),
'oauth_signature_method' => 'HMAC-SHA256',
'oauth_timestamp' => time(),
'oauth_token' => $accessToken,
'oauth_version' => '1.0',
];
$data['oauth_signature'] = sign($method, $url, $data, $consumerSecret, $accessTokenSecret);
//print_r($data); $curl = curl_init();
curl_setopt_array($curl, [
CURLOPT_RETURNTRANSFER => 1,
CURLOPT_URL => $url,
CURLOPT_HTTPHEADER => [
'Authorization: OAuth ' . http_build_query($data, '', ',')
]
]);
$result = curl_exec($curl); $orderData = json_decode($result,true); curl_close($curl);
echo '
?>` I tried it in the PHP script with the Integration user as well as the bearer token and it did not work in both scenarios. The main thing is that the live and local environment looks fine with the same code file and DB setup.
So my concern is that, Is any configuration on server can impact on this?
Proposed solution
No response
Release note
No response
Triage and priority