I have an MVC site that users Facebook to log-in users.
When trying to approve the Facebook app, the only field I can't get to be satisfied
is the
Privacy Policy URL field. I get the following error:
Can't seem to figure out what's wrong. The page is public and can be accessed without authentication.
It contains non-english text (hebrew).
Does the page content needs to comply to some structure ?
Have you looked at this? Facebook privacy policy error
You may have missed one of the requirements.
As WizKid says, it's was probably a temporary issue. Suddenly it just works.
The problem seemed to be just the fact that a previously fetched request for the same URL was not authorised by my server at that time. May be the same might have happened to you too.
Solution: Just fetch the URL of Privacy Policy again using Facebook's URL Debugger. That's the thing between you and your peace of mind.
Related
Since few days I have problems with the API instagram. Instagram sending this error page after the user has entered this login information.
"This page could not be loaded. If you have cookies disabled in your browser, or you are browsing in private mode"
Do you know why ? How to do ? Need help
On webapp authentication... the problem is related to instagram platform. I found that the problem arise only if your browser don't have the instagram cookie "ig_cb" set. This is set when you accept cookie policy on instagram.com. The workaround is to go on instagram and accept cookie policy then go back to your social auth and proceed.
This happens for both mobile and desktop users (browser).
Being a block on instagram login process... I guess there's no definitive solution other than wait for instagram bug fix.
I hate to be the bearer of bad news, but we also had this problem, which flagged on the Facebook Dev page: https://developers.facebook.com/support/bugs/406930029718049/
They have looked into the problem, as a number of us have had this exact issue too. It is only affecting EU user, as our US users are logging in and signing up without problems, and it seems that Facebook are refusing to look into it - their Instagram Platform API forum has already stopped accepting issues.
In terms of what we have learnt since last week, we think:
It is likely GDPR related
Not all apps have been affected, Bumble does not have this problem but Tinder does
It is happening with both the old Platform API and Graph API, according to a developer who has already migrated to Graph.
No one seems to know anything!
UPDATE:
So it seem's it is in fact a cookie issue on mobile. When a user goes to sign in on mobile view, the 'accept cookie' message that typically appears on web doesn't appear. However, when the error screen pops up, if you click 'Log in' in the top right, it will redirect you to the web view, which lets you accept the new terms and conditions. Then, once you direct back to mobile the cookie seems to have been saved and you can now login. This has worked for us on iOS so far, but not Android, and we still haven't come up with a work-around yet.
This bug has now been fixed.
Thank you all for your comments, individual input, and patience while we worked to address this issue for everyone.
I am happy to report that this particular issue with Instagram login should now be resolved, but if you are still seeing any issues related to this fix, please let us know on this report only.
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'm trying to integrate Paypal login within my Rails app and I can't make it work.
I was following the guide: http://cristianobetta.com/blog/2013/09/27/integrating-login-with-paypal-into-rails/
I created an application from the paypal developer site, and set the followings:
App return URL (test): http:/ /localhost:3000/auth/paypal/callback
App return URL (live): http:/ /localhost:3000/auth/paypal/callback
and I get the error:
"Relying Party Validation error: redirect_uri provided in the request does not match with the registered redirect_uri. Please check the request."
when I try to visit the URL:
http:/ /localhost:3000/auth/paypal
Interesting enough, I get the same error if I input my application credential in the official Paypal API integration tool:
https://devtools-paypal.com/guide/openid/ruby?interactive=ON&env=sandbox
Any ideas?
Thanks
This has changed a bit since the accepted answer, and will presumably change again soon... but here's how you do this now.
Log into developer.paypal.com
Click on Dashboard (https://developer.paypal.com/developer/applications)
Click your app name under "Rest API Apps"
Scroll to the box at the bottom of the screen labeled "Sandbox (or Live) App Settings
Set the Return URL (Where users will be redirected after test transactions)
Click save
NOTE
This Return URL must exactly match the redirect_uri that you pass in via querystring (so it's confusing as to why you'd need to pass it in in the first place)
GOTCHA
At this point in time, the Return URL can seemingly never be updated. In my recent experience, if you don't type it correctly the first time you save it, you will have to create a new app.
You need to set this value inside of your sandbox application on the developer website.
Log into developer.paypal.com
Click Applications
Under My Rest Apps click your App name
Click Edit next to App redirect URLs
Set the return URLs for live or test
Save
I resolved it by setting both the live and test redirect URLs to the same thing.
Plus, I ensured that I ticked to get Personal Information from the advanced settings panel, also adding URLs for privacy and agreement links.
The portal hung when set to localhost addresses for those links, so possibly PayPal tried to dereference them, so I put in real fake URLs.
I was encountering this issue myself, albeit in a Sinatra rather than Rails app - like you, I was using http://localhost:4567/auth/paypal/callback as the return URL - changing it to http://127.0.0.1:4567/auth/paypal/callback on the PayPal dev portal and accessing my app from 127.0.0.1 rather than localhost fixed it for me.
I'm trying to implement Soundcloud connect and having a weird issue.
First thing I do is send my users to
https://soundcloud.com/connect?client_id=MY_CLIENT_ID&redirect_uri=http://myredirecturl.example.com&state=RANDOM_STRING&display=page&response_type=code&scope=email
When users connect they get redirected to
http://myredirecturl.example.com?error=invalid_scope&error_description=The+requested+scope+is+invalid%2C+unknown%2C+or+malformed.&state=RANDOM_STRING
The same happens if I use scope=*.
However, if I use scope=non-expiring it lets me go through, but I need the users email and that type of scope doesn't have enough grants.
I thought it had something to do with my app being in development mode, but Osman at Soundcloud said it doesn't.
Thanks.
The 'email' scope is not available to all integrations. It's used for a few custom integrations that have provided us with accepted terms of service / privacy policies. There is no way to get a user's email address using the SoundCloud API.
You should however be able to use the '*' scope to get an expiring access token. I'll check with our app team to see why this is giving you an error. I'll edit my answer once I have more information there.
For your purposes, I would stay with the 'non-expiring' scope and simply prompt a user for their email address (providing them with a way to agree to your terms of use / privacy information).
Using scope=* sometimes doesn't work because the url is not properly encoded. If you are getting this error while using the * wildcard, try properly encoding the url, using a function like urlencode() (for PHP).
I'm using dotNetOpenAuth to provide SSO to my app via a user's Google Apps account. Besides just simple authentication I also ask Google to return the user's email, first name and last name. When a user first goes in they get redirected to the typical Google Accounts page telling them that the app is asking for this info and do they want to allow it. There is the checkbox there to Remember This Approval. The problem is, the approval isn't being remembered. It does remember them if they go back to the site without closing their browser. But if they close their browser and then open it later and go back in, they are again prompted to allow it.
If I look through my Google account page that shows me connected sites, apps, and services, I see my app listed multiple times. It's like it doesn't recognize that it's the same app and keeps adding it.
I know I must be missing something obvious, but I'm not sure what it is. Any ideas?
Thanks!
You can find my code here
I see several problems in your code. To first answer your direct question, the reason Google doesn't remember you on return visits is because you are passing a random GUID in as part of your Realm each time you log in. The symptom is actually much worse than you realize. It's not just that Google prompts the user on return visits, your site won't recognize the user at all on return visits because Google will give them a new claimed identifier on each visit.
The fix is that you should use the exact same Realm for every login request:
Realm realm = "http://www.yoursite.com/";
var req = openid.CreateRequest(discoveryUri, realm, URIbuilder.Uri );
Or my personal favorite:
var req = openid.CreateRequest(discoveryUri, Realm.AutoDetect, URIbuilder.Uri );
Realm.AutoDetect will work for you unless your site is available both via HTTP and HTTPS, in which case you need to lock it down to just one or the other of these so that Google recognizes your site as always the same.
You must also remember that the returnTo URL that you pass in as the 3rd parameter to CreateRequest must always be based on the realm. So if your realm is HTTPS, so must your returnTo parameter be.
I also want to call out that you seem to have some GUID code and complex URL manipulation around trying to ensure that every OpenID response you accept comes from a request you sent out. I'm not sure why you're trying to do this in the first place, although there certainly can be legitimate reasons. The way you did it is insecure and can be circumvented. I suggest you delete all this code, in favor of adding this to your web.config file:
<dotNetOpenAuth>
<openid>
<relyingParty>
<security rejectUnsolicitedAssertions="true" />
</relyingParty>
</openid>
</dotNetOpenAuth>
The library has support for requiring all responses to come from your requests built in, and it does so securely so that the security exploit I alluded to earlier isn't possible.
But if you're only trying to apply this restriction so that you know it's coming from Google, may I recommend that instead of rejecting unsolicited assertions, you instead check the IAuthenticationResponse.Provider.Uri property when you receive responses and verify that it is coming from the Google OP Endpoint? Then, if Google ever supported sending unsolicited assertions it would work on your site, and ultimately your security gate is exactly where you intended it to be anyway.