is there a way to disable the default canonical URL handling within SAP Spartacus?
It appears that since 4.x a default behavior has been integrated.
For the page type 'ProductPage' the 'setCanonicalLink()' in the 'PageMetaLinkService' is still triggered and removes our custom set canonical tag
Changing the settings in the config, as described in the documentation is not doing anything for the ProductPage: https://sap.github.io/spartacus-docs/html-tags/#canonical-urls
Cheers
Related
The Spartacus storefront has english as default language, i couldn't find a way to change this within the i18n settings in my app.module.ts, is there another way to set another language as default?
You can configure this in the context properties. There are two possibilities:
static, configured via javascript, see https://sap.github.io/cloud-commerce-spartacus-storefront-docs/static-context-configuration/
automatic, configured via site setup in SAP Commerce, see https://sap.github.io/cloud-commerce-spartacus-storefront-docs/automatic-context-configuration/
I want remove hashtag(#) from urls, but also i need to save no-reload mode. Can i do that?
I have: page.com/#/home
I want: page.com/home
I tried mode: 'history', but page reloads with it.
UPD: Is it possible to create SPA app without page reloading and with normal URLs?
When activating the history mode, you need to first configure your server according to the documentation. The reason for that is, that the history mode just changes the URL of the current page. When the user actually reloads the page, he'll get a 404 error, because the requested URL is not actually there. Reconfiguring the server to serve always the main index.html of your SPA resolves this issue.
When using a # in the URL (no history mode), the browser tries to navigate to the element with the ID, which was given after the # (within the same document). This was the original behavior of the fragment identifier. Therefore, if you add a link to your HTML with such a fragment identifier, the browser won't reload the page but actually look for the ID inside the document. The vue-router watches this change and routes you to the correct route. This is the reason it works with hashes. If you just add a regular URL to the HTML, the browser's native behavior is to actually navigate to this page (hard-link). This leads to your experienced reload effect.
The way to handle this, is, to never use regular links to route within a Vue Single-Page-Application. Use the tag <router-link> for routing between one page and another (but only within the SPA). This is the way to go, no matter if the browser allows the navigation with # without reloading or not. Here is the documentation for the recommended routing tag: link
You can also route from one route to another programmatically. Use $router.push() for that. Here is the documentation for that: link
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
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.
I can do this in FF and IE, and I know it doesn't exist in Chrome yet. Anybody know if you can do this in a Safari plugin? I can't find anything that says one way or another in the documentation.
Edit (November 2021): as pointed out in the comments, ParosProxy seems to no longer exist (and was last released ~2006 from what I can see). There are more modern options for debugging on Mac (outside of browser plugins on non-Safari browsers) like Proxyman. Rather than adding another list of links that might expire, I'll instead advise people to search for "debugging proxy" on their platform of choice instead.
Original Answer (2012):
The Safari "Develop" menu in advanced preferences allows you to partially customize headers (like the user agent), but it is quite limited.
However, if a particular browser or app does not allow you to alter the headers, just take it out of the equation. You can use things like Fiddler or ParosProxy (and many others) to alter the requests regardless of the application sending the request.
They also have the advantage of allowing you to make sure that you are sending the same headers regardless of the application in question and (depending on your requirements) potentially work across multiple browsers and apps without modification.
Safari has added extension support but its APIs don't let you have granular level control over Request & Response as compared to Chrome/Firefox/Edge.
To have granular level control over your Request and Response, you need setup a system wide proxy instead.
Requestly Desktop App automatically does this for you and on top of that, you can do various types of modifications too like:
Modify Request/Response Headers
Redirect URLs
Modify Response
Delay Network request
Insert Custom Scripts
Change User-Agent
Here's an article about header modification using requestly
https://requestly.io/feature/modify-request-response-headers/
Disclaimer: I work at Requestly