My application has a search functionality which uses a query param fullText for the search term. But on my QA server, any query parameters are being removed and csrf token is being added.
Example, on homepage, if I search for 'tax', the url should be:
https://www.qaserver.com/en/search.html?fullText=tax
Instead, it changes to below url and remains on the 'same' page it is on.
https://www.qaserver.com/en/home.html?%3Acq_csrf_token=eyJleHAiOjE1MDAyNDk5NzgsImlhdCI6MTUwMDI0OTM3OH0.EXoQy8xeVh3j9kdFdnenLGLl2sFEh_boi_jFareO1is
Is there any AEM/dispatcher config missing or incorrect ?
The dispatcher or AEM logs don't show who is appending this param or why.
The same thing happens with direct IP of publish server as well.
Include <cq:includeClientLib categories="granite.csrf.standalone"/> on the page from you are making POST ajax or form submit. This should resolve the issue.
Or the other option is to exclude particular servlet path from CSRF Filter Configuration (Which is not recommended).
Related
I am currently working on a 1 page HTML app that uses URL parameters to do an API call. the URL parameters are set and used in QR codes so its necessary that they are able to change dynamically. A example URL would be something like app.com/index.html/?environment=demo&location=Kiosk
I currently have this app deployed in AWS Amplify, but I cant get other keywords to chain together. I have the following redirects in place:
These redirects make sure that every URL parameter I pass in the link works EXCEPT some keywords like the "location" keyword, next to some others. Using this keyword as a URL param gives a 502 server error, or if the redirects are not used an access denied error.
does anyone know how to get the location keyword to work? Thanks in advance!
You should be able to use a single rule that will forward everything to index.html EXCEPT urls with a "file extension" from the list below. That lets all your links work, but assets like images, fonts, code will pass through.
Doc for: Using Redirects - Single Page Apps
</^[^.]+$|\.(?!(css|gif|ico|jpg|js|png|txt|svg|woff|woff2|ttf|map|json)$)([^.]+$)/>
In March of 2018 Facebook began requiring "Strict Mode" for redirect URIs. This means any redirect URI needs to be known in advance, and added to your app's profile (Valid OAuth Redirect URIs). The problem is when the redirect URI contains a dynamic parameter, like a state variable, guid, or user id, etc.
The answer I have found on many websites is that you can hold dynamic state in a "state" parameter. So if your allowed redirect uri is "www.example.com/signin" then this will also allow "www.example.com/signin?state=12344". However, this seems to be no longer allowed. The state parameter no longer seems to be ignored by this strict rule - it fails validation (there is a valid url checker on your facebook app settings page). To test this, I simply put "a.com" in the allow uri field, and "a.com?state=x" in the Redirect URI Validator, and it fails. Without the ?state-x it succeeds. What am I missing?
So I have two questions:
1) First, how to I find out what redirect url my app is actually sending to FB? I can't sniff my traffic since it's https (also required now by fb). I think I know what it is (https://www.example.com/signin-facebook?state=xxxxxx) but I can't be sure and there is no way to verify. The logic that calls FB is wrapped up in the MS Identity library.
2) Second, if it's the state parameter that is causing my login fails, is there any way to disable that in my ASP.NET Core app, or allow it in FB?
Just to clarify, here are two images showing that without the state parameter, the url is valid, but adding the state parameter makes it an invalid URL. Clearly the 'state' parameter is not being ignored by this strict rule checker, as many people have claimed. If I add the state param url to the list of allowed urls, it works but only with that exact state value, not with any different value.
The state parameter is dynamic to begin with (or at least it should be, because its original purpose is CSRF protection), so it is not taken into account when the URL is checked for a “strict” match to the one you have configured.
If you want to use
https://www.example.com/signin-facebook?state=xxxxxx
then configure
https://www.example.com/signin-facebook
as your Valid OAuth Redirect URI.
If you have other (static!) parameters besides the dynamic state, then those must be input into the field as well. You want to use
https://www.example.com/signin-facebook?action=foobar&state=xxxxxx
then the URL in your settings needs to be
https://www.example.com/signin-facebook?action=foobar
And since, as mentioned, the original purpose of this parameter is CSRF protection, it might still be a good idea to add a “random“ component to it, if the actual value you are trying to transport via it is “guessable”, or from a limited range of pre-defined values only.
In that case, I would probably go with an encoded JSON object as the parameter value -
state={"mystate":"foobar","random":8473628}
(Don’t forget to apply proper URL encoding, if your system doesn’t do that automatically.)
I noticed Amazon S3 Redirect rule - GET data is missing but after following the accepted answer my query params still are not being preserved.
I have a site that uses React and React Router, meaning I have several URLs that load identical HTML and JS and then the JS figures out which part of the app to load based on the URL.
For example:
/foo, /bar, /baz all should load index.html, which loads bundle.js. Then bundle.js observes the URL and routes to some React component (also in bundle.js).
However no foo, bar, or baz file exists in S3, only index.html. What I want to do is when I get a 404, redirect to /#!/{URL} (eg. /foo redirects to /#!/foo). This works fine with my redirect rule (below). However, I also want to bring query params with me (eg. /foo?ping=pong redirects to /#!/foo?ping=pong) but instead /foo?ping=pong just redirects to /#!/foo.
Here are my redirect rules:
<RoutingRules>
<RoutingRule>
<Condition>
<HttpErrorCodeReturnedEquals>404</HttpErrorCodeReturnedEquals>
</Condition>
<Redirect>
<Protocol>http</Protocol>
<HostName>www.mydomain.com</HostName>
<ReplaceKeyPrefixWith>#!/</ReplaceKeyPrefixWith>
</Redirect>
</RoutingRule>
</RoutingRules>
Any ideas on some way I can achieve this? Ideally without having to go change something in S3/CloudFront every time I add a new page?
The problem was that I had the origin set up in CloudFront not to forward Query Strings so when S3 got the request it would redirect properly without the query params. You can find this setting in CloudFront > Behaviors > Forward Query Strings.
If you want to have clear urls though you can also check out this trick. You need to setup cloudfront distribution and then alter 404 behaviour in "Error Pages" section of your distribution. That way you can again domain.com/foo/bar links :)
The menus and options in CloudFront/S3 change a lot over time.
Here is a December 2021 solution.
Step 1) Create a "Request" Policy in CloudFront that allows QueryStrings
Note: you might want to also add some Headers like Origin or Access-Control-... headers for CORS.
Step 2) Go to your Distribution > Update the Origin request policy
Step 3) Kick a new Invalidation on /*
Additional Notes for Debuging/Testing
I would recommend testing with curl in terminal rather than a browser to avoid caching and also seeing the details. I do curl -v https://example.com/cb?foo=bar1.
Keep increasing the value of the query string (bar1 in the above example, to bar2, bar3) with every test to make such there is no caching again.
I have a multiple publish instances and multiple dispatchers in Production environment of my website. While i see net tab in firefox, i see a failed request of tracker.js directly hitting to dispatcher URL.
GET http://web.dispatcher.com/libs/wcm/stats/tracker.js?blah-blah
where web.dispatcher.com
I feel dispatcher URL should not get exposed like this. And why even it is hitting dispatcher URL. Any ideas?
I feel either turn off the impressions tracker but not sure how to do that? Or rewrite the request to hide dispatcher. Any suggestions? And How to do it?
if you go to [host]:[port]/system/console/configMgr you will see a configuration for "Day CQ WCM Page Statistics"
Modify that to configure the full url where you want the tracker to send it's requests to.
Additionally, this XHR request is generated by stats.jsp, which is generally included in your head.jsp. If you simply remove that script include from your template (or change it to conditionally include, ie. to not include when WCMMode==DISABLED) you can stop that request from being generated.
I'm using OpenAM for authentication on my application. I access to my app using such URL:
http://my.company.com/appfolder/appservlet?lang=EN&user=test
On first access, OpenAM agent catches the URL and redirect my browser to the authentication page using this redirection URL:
...openam/UI/Login?goto=http%3A%2F%2Fmy.company.com%3A8080%2Fappfolder
After correct authentication, I'm finally redirected to the following URL:
http://my.company.com/appfolder
This is logic since this is the URL referenced in goto param. But it's not the same than original one: the servlet and custom params (lang and user) are missing.
Any idea how to configure my agent to make it keep servlet and params after redirection ?
take a look at this step of the tutorial "Add Authentication to a Website using OpenAM".
In section "Creating An Access Policy" -> "Wildcard matching" is your answer:
The wildcard * in policy URLs does not match '?'. As such if you
wish to allow GET parameters to be submitted then a second policy for
http://webserver.example.com/*?* is required.
Thanks for your answer. As mentionned in my previous comment, the adding of new policy does not resolve my issue. Actually, I'm not sure to understand how the policies can solve the issue since the goto parameter is generated by the J2EE agent, which acts before policies are applied (as far as I know... I'm maybe wrong).
Anyway, I could solve my problem by re-compiling the J2EE Agent: I've build a new agent.jar based on v3.0.3 available at forgerock. Then I replaced the AmFilterRequestContext.class by a new one, build on source available here:
http://www.docjar.com/html/api/com/sun/identity/agents/filter/AmFilterRequestContext.java.html
With this new agent, my goto is now correct, and redirection works well (and I don't have to define any policy).
The strange thing is that I don't understand why it works now ! I couldn't find any difference between java source mentionned above and uncompiled version of original class! I just added some System.out.println to get variables values and functions results, and built the jar. After restaring my jboss, the goto was correct. I'll try to understand why this finally work now when I've time.