Content encoding error when using linkedin.com/uas/oauth2/authorization - oauth

I'm developer working on integration between our product and LinkedIn. It's been decided we use https://www.linkedin.com/uas/oauth2/authorization to authenticate user. I found out the following issue, that I'll explain in detail below.
Positive scenario, everything works as expected:
when using valid client_id, everything is fine. To make everything clear, please see this URL (API key replaced with fake one):
https://www.linkedin.com/uas/oauth2/authorization?response_type=code&client_id=VALID_API_KEY&state=b4ac5e2ab5404d6fad2f25521d83e825&redirect_uri=http%3A%2F%2Flocalhost%3A8085%2Fapply-app%2Fpages%2Fsocial-networks%2Flinkedin%2Fauthenticated%3FsiteIdentifier%3DPIUFK026203F3VBLZ6G79V7OU%26token%3Db4ac5e2ab5404d6fad2f25521d83e825
When I remove client_id, everything is also fine and message is displayed (Missing client_id. A valid client_id is required to proceed.)
But when I use invalid client_id in browser I receive Content Encoding Error and http status code 500. URL: https://www.linkedin.com/uas/oauth2/authorization?response_type=code&client_id=invalid_client_id&state=b4ac5e2ab5404d6fad2f25521d83e825&redirect_uri=http%3A%2F%2Flocalhost%3A8085%2Fapply-app%2Fpages%2Fsocial-networks%2Flinkedin%2Fauthenticated%3FsiteIdentifier%3DPIUFK026203F3VBLZ6G79V7OU%26token%3Db4ac5e2ab5404d6fad2f25521d83e825
And the most interesting part goes here: when I fetch same URL using either wget or even java HttpConnection.connect() there result is different: HTTP status code 200 and html response. But when I started to analyze given output, I noticed that is ends up unexpectedly after <ul class="permissions, so it must me error in your code, that requires fixing.
I reported that, because it's quite inconvenient to support such behavior. Could you please inform me if you have any plans to fix this? If you need any further details regarding steps to reproduce this issue, please do not hesitate to contact me.
Best regards,
Piotr

Related

Brightspace / IMS-LTI content-item message problems

I'm trying to debug posting content via the Content Item Message spec back to Brightspace after a successful launch to my Ruby on Rails application – but I'm getting nothing but inscrutable 500 errors from the Brightspace server –– I presume that I am sending a bad signature (Brightspace confirmed this one time), but I haven't been able to find conclusive documentation on exactly how the nonce, timestsamp and signature are calculated, nor have I been able to find an open source library that appears to handle this.
Any advice appreciated.
I discovered that Instructure's ims-lti gem, although not documented, can generate signed params which can then be posted server-side or iterated through to render an HTML form client side, and then auto-submit, using the IMS::LTI::Models::Messages::ContentItemSelection class at /lib/ims/lti/models/messages/content_item_selection.rb

IE using Negotiate authorization instead of Basic

I initially asked this question, which shows that I see MVC errors of missing POST values. I was unable to reproduce - I still can't reproduce it on demand, but I did get the error myself on IE11, and I got a clue...
I have an application in IIS7.5 running with Basic authentication only. I look in Fiddler, and normally all transactions have Authorization: Basic xxxxx as expected. The body contains POST values as expected, and Content-Length is correct.
When I experienced this problem, I found that every single request (GETs and POSTs, including static content) was now showing Authorization: Negotiate xxxxx in Fiddler, with an empty body and zero Content-Length, even when I submitted a POST object via jQuery AJAX, and IE's dev tools shows the real POST body (which of course means IE is lying - not the first time). It gets a 401 response, and then a new request occurs with Basic, but also with an empty POST body, which means ASP.NET throws an error about missing parameter values.
Other web applications on the same top-level domain do use Windows authentication instead of Basic, and my suspicion is that the user goes to one of these sites, and IE becomes confused and thinks that my application should use Windows authentication as well - but I can't reproduce that every time. I have reproduced it twice, but out of a dozen or so times of doing the same thing over and over, so I'm not finding a way to make it reproduce every time.
I don't know why the POST body would get emptied, even if it does switch over and try to do WinAuth instead of basic - but that's when the problem occurs, so I'm sure it's related.
Any ideas on how to prevent IE from getting confused and using Negotiate, or at least how to detect and gracefully handle this on the server? I've only seen it in IE, but I can't be sure it's IE-only.
Here's what a normal POST looks like:
Then after the problem starts occurring, the exact same POST looks like:
EDIT
Here's an interesting edit - I just saw a new symptom. This time, all GET requests are coming in with no Authorization header at all, and the response comes back with a 401 for basic, and the GET is re-done properly with basic. But the POSTs are going through normally, with basic on the first try. I don't know what started this happening, but it's a similar symptom of the same problem.

How to block requests to server with user name / password?

We have realized that this URL http://Keyword:redacted#example.com/ redirects to http://example.com/ when copied and pasted into the browser's address bar.
As far as I understand this might be used in some ftp connections but we have no such use on our website. We are suspecting that we are targeted by an attack and have been warned by Google that we are passing PII (mostly email addresses) in our URL requests to their Google Adsense network. We have not been able to find the source, but we have been warned that the violation is in the form of http://Keyword:redacted#example.com/
How can we stop this from happening?
What URL redirect method we can use to not accept this and return an error message?
FYI I experienced a similar issue for a client website and followed up with Adsense support. The matter was escalated to a specialist team who investigated and determined that flagged violations with the format http://Keyword:redacted#example.com/ will be considered false positives. I'm not sure if this applies to all publishers or was specific to our case, but it might be worth following up with Adsense support.
There is nothing you can do. This is handled entirely by your browser long before it even thinks about "talking" to your server.
That's a strange URL for people to copy/paste into the browser's address bar unless they have been told/trained to do so. Your best bet is to tell them to STOP IT! :-)
I suppose you could look at the HTTP Authorization Headers and report an error if they come in populated... (This would $_SERVER['PHP_AUTH_USER'] in PHP.) I've never looked at these values when the header doesn't request them, so I'm not sure if it would work or not...
The syntax http://abc:def#something.com means you're sending userid='abc', password='def' as basic authentication parameters. Your browser will pull out the userid & password and send them along as authentication information, leaving the url without them.
As Peter Bowers mentioned, you could check the authorization headers and see if they're coming in that way, but you can't stop others from doing it if they want. If it happens a lot then I'd suspect that somewhere there's a web form asking users to enter their user/password and it's getting encoded that way. One way to sleuth it out would be to see if you can identify someone by the userid specified.
Having Keyword:redacted sounds odd. It's possible Google Adsense changed the values to avoid including confidential info.

OAuth in Jira - 'consumer_key_unknown' while requesting token

I am trying to connect to Jira using OAuth. I have followed this manual and I have created app link in Jira instance and configured it with proper consumer key and public key. When I try to request a token using code from the example I am getting 401 with following message (same for python and perl instance):
oauth_problem=consumer_key_unknown
I am out of ideas what can be wrong. I will appreciate any tips.
Well, I believe that I have configured Application link in the wrong place. I have been somehow navigated to the link wiki/admin/listapplicationlinks.action. Then I accidentally found plugins/servlet/applinks/listApplicationLinks which looked pretty much the same as first but content was different. I have added link to the second location and everything works well now. Sorry for confusion.
I also had this similar error. So I then used different "consumer key"(tried to make this unique) other than the given one in the example manual. After searching a lot in internet about this error, I got to know that as most people are using that same consumer key(given in example manual), a database error occurred due to which this error was thrown.

curl post testing oauth 2.0 not working while the http example does

I am trying to understand how Google authentication works with OAuth 2.0. They give some examples at this link.
I am having trouble with one of the first steps. I can execute this http request in a browser:
https://accounts.google.com/o/oauth2/auth?scope=https://www.google.com/m8/feeds&client_id=21302922996.apps.googleusercontent.com&redirect_uri=https://www.example.com/back&response_type=token
and that works fine.
When I try to convert it to a curl GET operation,
curl https://accounts.google.com/o/oauth2/auth?scope=https://www.google.com/m8/feeds&client_id=21302922996.apps.googleusercontent.com&redirect_uri=https://www.example.com/back&response_type=token
I get a response that tells me there is an OAuth 2.0 error: invalid_request.
Converting it to a POST, I can't get this operation to work.
curl http://accounts.google.com/o/oauth2/auth -d “scope=https://www.google.com/m8/feeds&client_id=21302922996.apps.googleusercontent.com&redirect_uri=https://www.example.com/back&response_type=token”
The response is that the document has moved.
If I try this, I get similar results.
curl http://accounts.google.com/o/oauth2/auth -data-urlencode “scope=https://www.google.com/m8/feeds&client_id=21302922996.apps.googleusercontent.com&redirect_uri=https://www.example.com/back&response_type=token”
I have never used curl or OAuth in my code before, so I want to understand some of these basics. Can someone tell me what is wrong with my GET and POST ?
I don't have a sure answer for you, but I was working on something similar for Instagram and one thing that stumped me for a while was that my redirect URL looked to be the same as Instagram expected, but I kept getting errors.
Like you, when I 'hand coded' the redirect URL, I got the result I expected, but my automated calls to the authentication URL failed. It turned out my ampersands were a url encoded which Instagram compared to the redirect URL and saw they were not identical. I'm not sure if that will get you closer to an answer, but I thought I'd share my experience since your question reminds me of the situation I was in. Good luck.

Resources