I have been using oauth 2.0 with Linkedin as the provider. Now as of today suddenly the authentication is no longer working. Looked on Linkedin its API profile page and figured that they have been updating their program.
The error that I am getting is the following:
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:3000' is therefore not allowed access.
This is in JS in the Console. I am wondering if this is the actual error or if there is another error.
I am using Rails on the back-end
LinkedIn February 12th 2015 update effects LinkedIn applications between May 12th - May 19th, 2015. Maybe, your application affected today.
I'm getting error after updating. Your application has not been authorized for the scope "r_fullprofile". The update affected somethings.
https://developer.linkedin.com/support/developer-program-transition
Figured it out! Not only on linkedin side, but also in your initializers you have to be careful with what you are asking for. So r_fullprofile is not longer part of Linkedin API (you have to ask linkedin to be able to make it work). There are also other API things that no longer work (e.g. r_connections), so be really careful as Linkedin has changed this policy.
In addition, you should not forget to reset the server to reinitialize the initializers.
Related
I want my app to chat.postMessages to Slack, using the icon_emoji and username parameters so that I sometimes change the icon and name displayed.
From the doc of the method, it seems I have to set as_user to false. But when I do so, I'm getting a missing_scope error: I need scope chat:write:bot. (Same error whether I use my OAuth access token or my OAuth bot user access token)
But from this page I got that they are disappearing? So are the parameters I want to use (icon_emoji and username) going to disappear as well?
No, as of Dec 19 2019, you cannot use icon_emoji, etc
I ran into the same issue, and so I opened a support ticket with Slack. After a few messages back and forth, I got confirmation that this is likely a bug:
With your help I was able to replicate the issue. I suspect this is a bug but I've escalated it to the Granular Bot Token team for a second opinion. As soon as I have more details I will let you know.
Edit:
I've received another update, which I've trimmed down to the essentials:
When building the Granular Bot Token model our team really wanted to use this as an opportunity to slowly deprecate certain API behaviour. The as_user parameter is one of them. See the following comment from (https://api.slack.com/authentication/quickstart).
One effect worth noting: chat.postMessage and other chat.* methods no longer mess around with the as_user parameter. You're granted a single chat:write scope (no :user or :bot is appended). If you call the chat.postMessage method with your bot token, you post as the bot. If you've obtained a user token through the new install flow, and you call the method with your user token, you post as the user.
So in regards to the action you are wanting to take, I'm afraid it's not possible with Granular Bot Token. We also recognized that the error this is throwing is completely unhelpful and confusing for developers. For this, we've created a bug to fix the error that's returned when Granular Bot tokens try to make restricted API calls.
I've requested clarification on whether it is just the as_user part that is deprecated, or the icon_emoji part as well.
Edit 2 (Dec 19, 2019 13:38 EST):
One, probably final, update:
The option for app to change information such as username, avatar and icon via the API is up for debate as well. Currently with Granular Bot Tokens you can only update that information via your API management page.
Which is really unfortunate.
I had to add a Scope to "Bot Token Scopes" with the value of "chat:write.customize".
https://api.slack.com/scopes/chat:write.customize
then I had to re-install my app. And it worked like I expected.
Note: I tried this as it was a suggestion from a comment. but it worked so i am adding it as an answer.
We integrated our application with LinkedIn for sign on over 6 months ago and it's been working fine. Today, we went to developer.linkedin.com for our application to update the "OAuth 2.0 Redirect URLs" to add an additional URL. We previously had the production domain, test domains, and localhost entered. Now, when we save, we receive the "One or more urls are not allowed." error message. Through process of elimination, it appears to not approve our test domain "relode-dev.azurewebsites.net".
I've checked with SURBL and none of the domains we're entering are blacklisted.
Can someone explain why "relode-dev.azurewebsites.net" is no longer valid when it was for 6 months?
After experimenting some more, it looks like LinkedIn doesn't allow any *.azurewebsites.net domains any more. I'm not sure why they created this policy. For now, the workaround seems to be adding your own custom domain to your Azure website and using it in the LinkedIn OAuth 2.0a Redirect URL. You can follow the article at http://azure.microsoft.com/en-us/documentation/articles/web-sites-custom-domain-name/ to set up your custom domain.
If LinkedIn reads this, it would be nice if you notified third-party developers when you make policy changes like this. We've had to scramble for the past few days to workaround this change.
edit: fixed the url to the azure help page (it had an extra word on the end causing it to 404).
I am trying to implement oauth2 for yahoo (target is yahoo's contact api). See here: https://developer.yahoo.com/oauth2/guide/#implicit-grant-flow-for-client-side-apps
However, I get the following error:
Oops. Yahoo is unable to process your request.
We recommend that you contact the owner of the application or web site to resolve this issue. [95037]
How to get this resolved? It comes with I use response_type=token (which is needed for Implicit Grant Flow), but works fine for response_type=code
[EDIT]
The request to yahoo (urldecoded):
https://api.login.yahoo.com/oauth2/request_auth?client_id=[CLIENT_ID]&response_type=token&redirect_uri=[PATH]&display=popup&scope=&state={"client_id":"[CLIENT_ID]","network":"yahoo","display":"popup","callback":"_hellojs_23g8z6wk","state":"","redirect_uri":"[PATH]","scope":"friends,basic"}
[UPDATE]
After following the recommendations from HansZ., I was able to resolve it.
Now the issue has come back without changing any code. Basically, it only works when I am logged in with the Yahoo ID that I used to setup the App at Yahoo.
Otherwise, sometimes it goes in loops and chrome says
This webpage has a redirect loop`
rest of the time it gives the error again.
Your state is the problem. I can reproduce the problem by including your URL-encoded state in the authorization request for my Yahoo client. The problem is the length of the state or the total URL. You may revert to using a cookie for maintaining that state and send only the (much shorter) cookie name as the state parameter.
I'm trying to develop a desktop application to access an API exposed by Groundspeak for geocaching.com. The API requires the use of OAuth.
After finally figuring out why my message signature was being rejected (I had to double-encode my callback URL, after reading somewhere that double-encoding causes problems), I now receive the following error from Groundspeak when attempting to get a request token:
oauth_error_message=Error%20while%20reading%20message%20%27DotNetOpenAuth.OAuth.Messages.UnauthorizedTokenRequest%27%20parameter%20%27oauth_callback%27%20with%20value%20%27http%253A%252F%252Fwww.mysite.com%252F%27.
Not a very descriptive error message. What's the problem here? Groundspeak uses DotNetOpenAuth on its server. Seems like my callback URL might be causing some issue, but I don't have any idea what.
I should probably also say that I'm developing a desktop application, so the callback URL isn't really valid. It does point to a website I own, but that website has no idea about OAuth at all. If I omit the callback URL, I receive the error "Callback URL not present or not valid" or somesuch.
I don't know anything about Groundspeak but I'd guess that they require that you register your app's callback URL before using OAuth. At least Google and Microsoft do this with their OAuth APIs. Look for some kind of developer settings on Groundspeak.
This is definitely something that needs to be further defined in the future: OAuth for non-web applications. But there does seem to be a few possible solutions (not the cleanest) that you can try to get OAuth working within a desktop application. You can look into the articles below that have some working solutions (I have not tested this myself). It's based off of Google's workable solution for handling OAuth from installed desktop apps:
https://developers.google.com/accounts/docs/OAuthForInstalledApps
Link to possible workaround solutions:
http://blog.appharbor.com/2012/06/21/oauth-for-net-desktop-applications
Here's also a related article on SO for desktop app OAuth: OAuth for Desktop apps?
Hope this helps!
I am using the ruby twitter gem and oauth to gain access to users twitter accounts. In my code, I have:
unless #user.twitter_authd?
oauth = Twitter::OAuth.new('token', 'secret')
session[:twitter_request_token] = oauth.request_token.token
session[:twitter_request_secret] = oauth.request_token.secret
#twitter_auth_url = oauth.request_token.authorize_url
end
where token and secret have my actual token and secret inserted. When I click on the link to the #twitter_auth_url, I am taken to twitter and asked to grant access. I click allow and then twitter redirects me to my callback URL http://www.mydomain.com/twitter_callback/?oauth_token=fmy2aMvnjVgaFrz37bJ4JuB8r5xN79gsgDQRG4BNY which then hits this code:
oauth = Twitter::OAuth.new('token', 'secret')
logger.info("session[:twitter_request_token] = #{session[:twitter_request_token]}")
logger.info("session[:twitter_request_secret] = #{session[:twitter_request_secret]}")
oauth.authorize_from_request(session[:twitter_request_token], session[:twitter_request_secret])
session[:twitter_request_token] = nil
session[:twitter_request_secret] = nil
#user.update_attributes({
:twitter_token => oauth.access_token.token,
:twitter_secret => oauth.access_token.secret,
})
redirect_to root_path
The twitter request token and secret are being set just fine. However I end up with an authorization error:
OAuth::Unauthorized in MainController#twitter_callback
401 Unauthorized
RAILS_ROOT: /Users/TAmoyal/Desktop/RoR_Projects/mls
Application Trace | Framework Trace | Full Trace
/Library/Ruby/Gems/1.8/gems/oauth-0.3.4/lib/oauth/consumer.rb:167:in `token_request'
/Library/Ruby/Gems/1.8/gems/oauth-0.3.4/lib/oauth/tokens/request_token.rb:14:in `get_access_token'
/Library/Ruby/Gems/1.8/gems/erwaller-twitter-0.6.13.1/lib/twitter/oauth.rb:29:in `authorize_from_request'
/Users/TAmoyal/Desktop/RoR_Projects/mls/app/controllers/main_controller.rb:70:in `twitter_callback'
The code is failing at this line:
oauth.authorize_from_request(session[:twitter_request_token], session[:twitter_request_secret])
when it tries to get an access token. You can see the source code of authorize_from_request here. I am not sure why this is happening. Anyone have ideas?
A bit late to the party but just ran into the same issue myself. I tracked the issue down to the setup of my OAuth app in Twitter. I had initially not specified a callback URL as I was unsure of it.
Once I had setup my rails app I went back to find Twitter had assumed I was a desktop application as I hadn't specified a callback URL. Once I changed this to website and entered a callback URL I stopped getting 400s.
If you're getting error 401 - OAuth::Unauthorized, make sure you edit the settings of your Twitter application as follows:
Application Type: Browser
Callback URL: http://127.0.0.1:3000/auth/twitter/callback
this is an issue about time synchronization of your system with twitter server.
Twitter doesn't allow localhost as part of a valid callback URL.
Instead use http://127.0.0.1:3000/auth/twitter/callback
Hope this helps
This was one of the most annoying things to debug that I have come across. I was outputting in a couple places by accident because the URL's are dynamic and they happened to not be defined in my test case (i use this to display chart data and there is not enough right now so the google chart api URL's are blank). This caused my browser to make multiple requests to my localhost when some pages were loaded. Somehow that made the oauth process crap out. Obviously there is no way for people on S.O. to know about my application specific issue so I had to answer my own question.
I had this same problem and none of the suggestions in this thread worked for me.
I found the problem for me was the TIMESTAMP on my request. The mobile device I was running my scripts on had a jacked up clock. When I updated the system time on my device to the correct time (i.e. now), all of my requests came back "200 OK" instead of "401 Unauthorized".
This problem seems to be caused by twitter not being able to handle connection keep-alive correctly. Make sure you set connection=close http header in the request to twitter. Wasted a weekend debugging this.
not enough info for me, but when was twitter gem last updated? twitter changed their oauth 'stuff' in mid may approx. perhaps you have an old one. I'd update your question to show the callback_url, and make sure you have the right token and secret, which it looks like you don't have.
also, did you put the right callback url in your twitter app page? alot of times that screws you up too.
if that fails use mbleighs twitter_auth instead. it worked for me and is pretty slick.