I recently started using SAML for my website's authentication which is working great except 1 particular problem.
Some users (all of them are in the same domain group policy if that helps) get an error while loading the website :
A potentially dangerous Request.Form value was detected from the client
I know this error doesn't occur because of the website's code since it always worked and still works fine on 95% of the users.
I've done some reading on SAML and it seems the SAML request is transmitted via the URL by encoding an XML-like message :
<samlp:AuthnRequest>
to get this base64-encoded message :
https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=fZFfa8IwFMXfBb9DyXvaJtZ1BqsURRC2
Mabbw95ivc5Am3TJrXPffmmLY3%2FA15Pzuyf33On8XJXBCaxTRmeEhTEJQBdmr%2FRbRp63K3pL5rPhYOpkVdY
ib%2FCon%2BC9AYfDQRB4WDvRvWWksVoY6ZQTWlbgBBZik9%2FfCR7GorYGTWFK8pu6DknnwKL%2FWEetlxmR8s
BHbHJDWZqOKGdsRJM0kfQAjCUJ43KX8s78ctnIz%2Blp5xpYa4dSo1fjOKGM03i8jSeCMzGevHa2%2FBK5MNo1F
dgN2JMqPLmHc0b6WTmiVbsGoTf5qv66Zq2t60x0wXZ2RKydiCJXh3CWVV1CWJgqanfl0%2Bin8xutxYOvZL18NK
UqPlvZR5el%2BVhYkAgZQdsA6fWVsZXE63W2itrTQ2cVaKV2CjSSqL1v9P%2FAXv4C
Now, If the XML-like message was encoded, there wouldn't be a problem transmitting a few characters over the URL. I suspect the problem is that the XML-like message is being sent without being encoded resulting in illegal characters ('<', '>') in the URL.
NOTE : The first time they open the website is successful, the error occurs only after the first time. If they clear the cookies they can open the website. (again, only once, then the error occurs until they clear the cookies again)
Does anyone has any idea what could be the cause of the message not be encoded for certain users/computers? or how can I know which URL is the SAML generating (so I can find out if the XML is really not being encoded)
The problem was that the page address was :
https://ServerName.ServerDomain/AppName
and some users were using this address :
https://ServerName/AppName
Related
I am using a plugin on a WordPress website which is supposed to feed gravity forms submissions into hubspot however, on submission I get the following error:
PHP Fatal error: Uncaught GuzzleHttp\Exception\ClientException: Client error: POST https://forms.hubspot.com/uploads/form/v2/XXXXXX/97d44f1e-XXXX-XXXX-XXXX-e4c453843854 resulted in a 404 Not Found response:
I've nullified the URL.
I've searched this error and read through many, many GitHub threads but no seem of any use to me - they're all about other people's bespoke implementations. Can anybody here shed any light on this for me? Is there any more information I can post to allow anybody to help me investigate deeper?
Some temp fixes I've seen circulate:
1) On your Hubspot forms, make sure they are using Thank You messages and NOT the redirect to page feature (neither are actually functional if you are using only this plugin making API requests and not using for form embed code etc provided by HubSpot)
2) Save / update your forms in HubSpot
Since doing the above (there was a mixture of the two in our case, we have not caught any further errors for the past couple days) Jury is still out on what is the true issue behind this.
Details:
I hit this issue as well. Guzzle is throwing the error after seeing the HS response. This Guzzle client was not used in the older version of the plugin, so thinking that either the request was different in previous versions (prior to v3) or HubSpot was throwing a 404 response before and it was being ignored. Data (in my testing) is still posting correctly to the HubSpot API and shown/updated in the Contact record database. But website users end up seeing a 500 error due to this issue. (As a result the analytics scripts on the thank you page never get fired so we caught this seeing a drop in GA) I'm assuming the plugin could be coded around this to ignore the exception, but still no idea why it is being provided as a response in the first place.
I do not want my users to authenticate. But I do not anyone to steal my data. So my goal is to only serve the people who make a req from the front end of the app. How can I do this ?
Is there a built in function that I'm missing ? I know that there are session id generated, but not sure how to incorporate the session id to this situation.
Thanks
By using the term "front end" I would assume that you have a client requesting data in the form of JSON/XML or HTML templates. My first suggestion to get your answer is to be much more descriptive in your question. It is very hard to answer without knowing how your client is designed.
Assuming your client is written in html/js and run in a browser then I would suggest that you serve a static file (in the form of a .js file or a <script></script> tag inside an html file) that generates a token. You can pass this token back to your server for validation on every request for data. This means that only your app (front-end) can be the only thing that requests data from your api (back-end).
Please consider the following two websites that I am pinging as shown in the image below:
I have a google plus login icon where a user can click on it and can sign in using his/her google account.
My website where all the login code is residing is say for example xyztesting.com as shown in the image. And all the code related to xyztesting.com resides on the box 10.11.10.12 which has a domain name abctesting.com.
So, when i ping abctesting.com, I get Packets Sent and Received = 4 as shown in the image.
However, when I ping xyztesting.com , I get Request timed out as shown in the image below.
Does anyone knows whether this could be the reason behind why I am getting Redirect URI Mismatch error 400 error whenever a user tries to log in using google plus ?
I have ensured that the REDIRECt URI in the request matches the Registered Redirect URIs which is the most common message displayed when some one encounters this error and this is the most common fix suggested online everywhere.
I have referred to lot of previous related posts, including this one where they talks about making sure that the request URI's should match the registered URI on google developer console.
I have got a feeling that since there is not a dedicated box/server for my website xyztesting.com, google is thowing such error. Please let me know if anyone has experienced such type of error with the situation I have described above?
Sometimes, the redirect uri should be set to "postmessage" not the actual uri.
The documentation is not so clear on that setting.
-Dragonfire
We received a request to create a REST api. I was a little confused in the example of provided by our client. As you can see below, they've identified the app_id and secret in the URL before the #. The remainder of the URI looks like what I would expect.
Is this valid? I thought maybe this is some weird cURL format I haven't seen before.
https://{application_id}:{api_secret}#api.example.com/entity/{entity_id}/
https://{application_id}:{api_secret}#api.example.com/entity/{entity_id}/entity_locations/{locations_id}/
Just seeing if anyone has seen this format before?
A URI is made up of various parts, one of them being the authority part, which can feature optional username:password element.
The full scheme is:
scheme://username:password#domain:port/path?query_string#fragment_id
This way your REST api remains stateless [not relying on previous app states like storing stuff in session]. But I advice you not to explicitly go with the username:password#stuff route, but to rely on Basic HTTP Auth, so the credentials are sent encoded in Base64 at least.
EDIT: a brief note about BasicAuth now you're asking - things go like this:
you make a request to http://johndoe:12345#service/api/foo/bar;
are credentials good? Ok, you get a 200 OK response with proper body;
are they not? You get a 401 Unauthorized response.
In the latter case, it's the browser [or any other program / script performing the request] that should prompt the user with the login popup.
Usually browsers ask you to cache credentials not to ask them every time, but this does not mean that they are not sent - it's just that every request to protected resources are featured with such header:
Authorization Basic base64encode(username:password)
Where base64encode is your custom way to encode the username:password string.
Seems like a lot of people have problems getting oAuth to work with Photobucket and now I'm one of them, I keep getting:
"Authentication failed signature check failed"
When trying to get a request token, here is the header info I send along:
OAuth realm=""
oauth_consumer_key="XXXXXXXXX"
oauth_signature_method="HMAC-SHA1"
oauth_signature="BHHJ4o7zXOlfln4Xpik5rPtjZv8%3D"
oauth_timestamp="1323470655"
oauth_nonce="2FEC3150-8AB9-4BBC-BC4B-FA5AE7EC8046"
oauth_version="1.0"
and my BASE string used to generate the signature:
POST&http%3A%2F%2Fapi.photobucket.com%2Flogin%2Frequest&format%3Djson%26oauth_consumer_key%3DXXXXXXXXX%26oauth_nonce%3D2FEC3150-8AB9-4BBC-BC4B-FA5AE7EC8046%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1323470655%26oauth_version%3D1.0
Everything seems on the up and up and I'm using the same library that I've been using for several other photo/video sharing sites with no problems, this is on iOS...
Thanks
Turns out that even though photobucket causes your requests to sometimes go to api####.photobucket.com (your special load balancing URL) you still have to specify your base string as api.photobucket.com which makes no sense and TOTALLY BREAKS oAuth since you're now setting your base string to a different url than where you're making the request :p
So, be vigilant and always make sure your base string is api.photobucket.com
sigh