Is there a way to remove the p_auth in the POST header, but still having it in the body? I still required the authentication check, therefore disabling it is not the option. Thanks
I know that this is an old question but there is no answer yet. You should enable friendly url mapping in Liferay. This involves creating a xml config file describing the url patterns and routes. You can find some information on it here.
Once it is enabled you can specify the p_auth parameter to be hidden from the url.
Related
I want to add a sort of custom middleware in Traefik, where I can check user identity and after validating from the database, I want to route users to different versions of the application? Is it possible with Traefik?
For the time being, the only way to add a custom middleware to Traefik is to fork it and add your custom middleware into the source code and build it for yourself. Actually this is not too difficult but of course it comes with all the downsides of forking. There is an example here: https://github.com/negasus/traefik2-luascript. You need to edit it a bit because it is somewhat outdated but I was able to add my custom middleware by following it.
We ran Burp Suite on our product and found some security vulnerabilities. The tool detected some of the CGI files which are vulnerable to Cross-Site Request Forgery attacks (CSRF).
As usual I did search for CSRF protection module on CPAN and found CGI::Application::Plugin::ProtectCSRF.
I'm wondering how can I integrate this module into our application in a generalized way? The documentation is not clear to me. How do I configure this module and make minimal changes to make sure whole application is secured from CSRF.
I also came across mod_csrf (an Apache module to prevent CSRF). Is installing this module and setting below in apache configuration file enough to prevent CSRF?
<VirtualHost>
CSRF_Enable on
CSRF_Action deny
CSRF_EnableReferer off
</VirtualHost>
I can understand that you found the documentation for CGI::Application::Plugin::ProtectCSRF unclear: it is a little impregnable
All that the Perl module appears to do is to add a hidden field to each HTML form with the name _csrf_id and a random value derived from various sources and encoded through SHA1. The protection comes when the response from the client requires that the same value must be returned to the server
It is quite nicely coded, but it uses custom subroutine attributes, and the documentation for the attributes pragma says this
WARNING: the mechanisms described here are still experimental. Do not rely on the current implementation
I cannot tell from my quick review whether the subroutine prototypes are essential to the module, but I recommend that you use the Apache mod_csrf module instead, which is likely to be more thoroughly tested than the Perl module, and has proper documentation
Since we were using in house server, not apache, therefore, mod_csrf was not possible to implement.
I ditched ProtectCSRF module as the documentation was unclear.
I solved it by doing below:
Add an element in header template which is common to all pages, this element contains CSRF token which is being passed from server
Create a JavaScript function and bind it to onload event. This JS function does below tasks:
a) Find forms in current page
b) If forms are found then create a hidden "input" element and append it to each form
c) Take the value which was put in header and assign it to above created elements
d) Now all forms have a hidden input element which contains CSRF token from point 1
Now whenever a form gets submitted this hidden element will also be submitted, whose value we are verifying at server end. If tokens do not match then there is CSRF, for which we throw the error and block request
I defined a new URI scheme on my Windows system (following this thread: how do I create my own URL protocol? (e.g. so://...))
I want the custom URI protocol to act like HTTP within Chrome/Firefox...
That is, I want: myprotocol://localhost/test.html
to act exactly like:
http://localhost/test.html
Is it possible, or does the browser insist on valid URI schemes, even if they are fully defined in the registry?
(This pertains to a local server and is required for personal application testing; I realise custom URI's are a bad standard and should not be used in production)
It is certainly possible to link a custom scheme to the browser of your choice. The challenge is to get the browser to treat your scheme exactly like http:// as it cannot possibly know it has to speak HTTP to the target resource. However, this answer suggests using an <iframe/> is a viable workaround.
From the Magento wiki at:
http://www.magentocommerce.com/api/rest/authentication/oauth_authentication.html#OAuthAuthentication-OAuthProcess
When getting an API token you start off by getting an Unauthorized Request Token at:
www.mystore.com/oauth/initiate
However, my code does not work and when I browse to the above url in my browser I get a 404.
I am appending shop store code to the base url (eg www.mystore.com/en/) I don't know if this alters anything.
The Magento Wiki has a typo:
$adminAuthorizationUrl = 'http://yourhost/admin/oAuth_authorize';
Should be:
$adminAuthorizationUrl = 'http://yourhost/admin/oauth_authorize';
I struggled with this one for most of the day, so here's a late contribution in case it helps anybody:
The authorization URL that's documented by Magento, admin/oauth_authorize, assumes that you're not using a custom URL for your admin access. "admin" is the standard URL to access the Magento dashboard, but many people change it for security. If you have changed your admin URL to something other than "admin", use that instead.
IOW if you access your Magento dashboard at https://yoursite.com/foo, then your authorization URL is foo/oauth_authorize.
I also had the problem, that the following request returned the 404 http status:
http://yourmagentostore.com/oauth/initiate
The solution was quite simple: In case if you are using multiple stores and/or store views on the same domain, don't forget to add the url path which maps to the store view. E.g.
http://yourmagentostore.com/<my-store-view-path>/oauth/initiate
I just had the same problem. Not many similar problems to be found and no solution. This is strange because this seems to be a missing config option 'global/request/direct_front_name', which isn't set in Core/Oauth module. How can all the tutorials work without this important setting!?
Without "oauth" setting being there, every call to /oauth/[controller] leads to "noRouteAction" being resolved (see. Mage_Core_Controller_Request_Http::setPathInfo() and Mage_Core_Controller_Request_Http::isDirectAccessFrontendName($storeCode)) instead of default indexAction.
So, the solution is to set this setting in local config or an own extension as follows
<?xml version="1.0"?>
<config>
[...]
<global>
[...]
<request>
[...]
<direct_front_name>
<oauth/>
</direct_front_name>
</request>
</global>
</config>
Afterwards you can finally get the token at least. I'm checking the further process now.
There is one subtlety don't forget the http:// so your call to the store should be
http://yourmagentostore.com/oauth/initiate
Also there is more to REST services setup then on the link you posted, it is only an overview. There is a ton of configuration on the store before you will actually get a rest response and when the user isn't recognized, unauthorized or without proper ACL privileges you will get 404 or 500 responses. I guess that deters hackers but it is a bear to trouble shoot. I've been down this road and although I am using an automation tool the Setup of the store and troubleshooting is the same.
Take a look on my blog I keep it up to date with my adventures with the Magento REST API
Cheers!
Rich Borek
http://magento-simplified.blogspot.com
I was googling for tools for checking broken links in a remote web page. The w3c validator seemed a good one. But I am still unsure as how to check for pages which are restricted, i.e. the pages which I can only access by logging in to the site. Can we do that using the w3c validator? If not than is there any other tool for the same?
For basic authentication the online validator will proxy it and prompt you to logon, alternatively see this post.
Sometimes you can specify the login details in the URL: username:password#url.to.the.site. This I believe only will work if you are using a .htaccess file for logins.