I want to start my Dropbox-app by linking to a dropbox account as specified here:
https://www.dropbox.com/developers/datastore/tutorial/js
However, dropbox won't redirect back to my website and throws "Invalid redirect_uri"
I specified various redirect urls and double checked my app_key, but i could not get it to work. What am i doing wrong?
Thanks in advance!
When I had this issue, I realized that when refreshing the dropbox app console page, it hadn't saved my domain value. Apparently, ONLY HTTPS prefixed domains will work. When I added https it worked fine and saved my value, then I was able to get that to work with my javascript, but I was wishing that I didn't have to setup a server with a cert just to test. Security security, I guess.
http://blah.com // didn't work
https://blah.com // did work
Make sure the full, exact URL is registered as a redirect URI. (E.g. https://www.mydomain.com/mypage.html) The error message in the browser should tell you the exact URI that was attempted, so you should be able to match it perfectly.
I am brand new on this and ran into the same issue today attempting to follow the "Dropbox Datastores and Drop-Ins" tutorial on net.tutsplus.com
My setup is on a local system as well with the solution in a sub directory called "todo".
By trial and error, I got through to the authorisation screen by adding this URI in the Dropbox Developer Console: "http://LH.LH/todo/" (without quotes, AND because of comment restrictions on this board, please replace "LH.LH" with "localhost")
Btw I can see in the console, that there are some other issues with the code, but I will be looking into that.
I'm facing the same issue. It works fine locally, but not on production. I find it to be because of the redirection URI: it adds the 'http://' bit, while you can't add this to the list of supported URI in the Dropbox app list.
Try changing the url manually from the browser, removing the http:// and leaving only the domain. Does it work? If so, you have the same problem as I do... which I still don't know how to fix :(
Related
I have the following code in flutter trying to retrieve an oauth2 token via auth code with PKCE flow:
final FlutterAppAuth appAuth = FlutterAppAuth();
final request = AuthorizationTokenRequest(
B2C_CLIENT_ID,
B2C_REDIRECT_URI,
discoveryUrl: 'https://$B2C_DOMAIN/.well-known/openid-configuration',
scopes: ['openid', 'profile', 'offline_access'],
// promptValues: ['login']
);
final AuthorizationTokenResponse result =
await appAuth.authorizeAndExchangeCode(request);
When this code is run in iOS, the browser opens and I can see it tries to load the signin page, but then immediately closes. No exceptions are thrown or anything. The code basically hangs at appAuth.authorizeAndExchangeCode almost like it doesn't know that the browser has closed.
I am not sure what could be causing this.
The code correctly determines the url for showing credentials using the discoveryUrl (i.e. it makes the http request first using the discoveryUrl) but not sure why it basically hangs after.
I am using azureb2c for authentication here.
Edit
Ok turns out this is a problem with using azure b2c in particular as tried it with a different identity provider and works fine.
I managed to locate the issue and fix it now a login page shows in the browser. After entering credentials, browser closes, but code still hangs on appAuth.authorizeAndExchangeCode(request); and does not proceed.
Also found existing issue. on github: https://github.com/MaikuB/flutter_appauth/issues/182
I managed to solve this following the below answer on the Github repository of the flutter_appauth plugin.
https://github.com/MaikuB/flutter_appauth/issues/182#issuecomment-840707729
Eventually, all I had to do was to add a trailing slash to the redirect url parameter in AuthorizationTokenRequest.
(It looks like Azure AD appends on a trailing slash to the redirect url which causes the validation in AppAuth to fail).
My app worked correctly with the slash both on Android and iOS.
P.S. If this doesn't work for someone, try to adjust the redirect url in your App Registration as suggested in the respective thread https://github.com/MaikuB/flutter_appauth/issues/223.
I suspect this is related to the call to resumeExternalUserAgentFlow, so here is a plan of action for you:
Follow the steps in my blog post to get the AppAuth Swift + Carthage sample working - which also uses a Private URI Scheme. Use my online configuration details as specified in the blog post and you should have a working solution. I have just verified that my instructions still work.
Update the same sample to use your Azure AD configuration and see if it still works. If so then there is nothing wrong with AppAuth and the problem is in the Flutter layer.
If the Swift sample fails when you update to Azure AD configuration, add some print messages for the URL being supplied to resumeExternalUserAgentFlow in the AppDelegate class, and see if this is different to the original redirect URI. If the redirect URIs are different, reset to the original value and hopefully that will resolve things.
Everything was working fine and Omniauth has stopped working suddenly. I didn't make any code changes.
I checked Twitter Apps Settings:
I have callback url to my main production url, and Callback URL Locked to No. All keys are correct.
Any idea? 🤔
OAuth::Unauthorized
403 Forbidden
I have been able to solve it (also for development) adding this urls:
For production:
https://mydomain/users/auth/twitter/callback
http://mydomain/users/auth/twitter/callback
For development:
http://localhost:3000/users/auth/twitter/callback
Now on twitter callback URL, you must have to add 2 callback URLs and the callback URL must be the path of your application.
I had faced the same problem, now on adding the 2nd callback URL, it's fixed.
For more information check: https://twittercommunity.com/t/action-required-sign-in-with-twitter-users-must-whitelist-callback-urls/105342
Adding a second Callback URL to https://mysitecom/auth/twitter/callback fixed the issue (for now)
———-
Update: This actually solved the problem for about 10mins. Experiencing the same problem now
I'm working in development not production and encountered this problem using the omniauth and omniauth-twitter gems. But with these two callback URL's:
http://127.0.0.1:3000
http://localhost:3000/auth/twitter/callback
the problem is avoided. Strange, since the RailsApps tutorial warns against using 'localhost' at Twitter.
This is almost certainly related to this change: Action REQUIRED - Sign in with Twitter users must whitelist callback URLs.
From the link:
In 30 days, we will begin enforcing the whitelist such that any URL
not added to the whitelist will fail. This means that URLs can no
longer be programmatically overridden in calls to the
oauth/request_token endpoint 112. The callback_url parameter provided
must match one of the whitelisted callback URLs. While we generally
provide longer than a 30-day notice for changes like this, this
timeline allows us to continue to provide a safe and secure experience
for developers and our users.
You can add callback URLs to your whitelist on the applications
settings page on apps.twitter.com 488.
Enable the setting “Enable Callback Locking” to test that only URLs
you have whitelisted are accepted. Callback URLs will automatically be
locked and the whitelist will be enforced starting on June 12th. The
“Enable Callback Locking” setting will be removed on this date.
I could not get this to work in development with 127.0.0.1 so I ended up creating a DNS A record that pointed to 127.0.0.1 (e.g., dev.example.com) and used that in the callback url settings on https://apps.twitter.com.
Unicode domain name. Twitter give me error: unsupportable domain name format. I need exactly match callback url, sending by my server and callback url in my twitter app.
Solution:
config/initialization/twitter.rb
OmniAuth::Strategies::Twitter.class_eval do
def callback_url
return my_custom_twitter_app_callback_url_string_variable
end
end
I just resolved the issue by putting https://domain/oauths/callback in the Callback URLs list. Make sure you enable the callback locking option.
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 have a Facebook app page and a rails application. My rails application loads a dynamic page based on a key that is given. This works fine and dandy outside of my facebook app:
https://app.eventsent.net/event_lists/3d40ba2a4a10947c17c2337fba3421dd406cceb5?frame=true
However inside of Facebook the page is pulling up as a 404 error:
https://www.facebook.com/reynoldsdesignstudio/app_419134091467471
I have gotten around this issue by creating a static file within my system to be able to have facebook view it however this is not ideal as deploying the rails app with updates makes modifying these static pages a pain.
Any help on this would be great.
We got this figured out by changing the routes file to allow for a post request instead of just a get request
Your problem is not related to dynamic/static content. Also Facebook is showing a 501 error, not a 404. In short, your SSL cert is not valid for the staging.app subdomain you are pointing your Facebook page at.
Visiting your Facebook page (https://www.facebook.com/reynoldsdesignstudio/app_419134091467471) yields this error:
This webpage is not available
The webpage at https://staging.app.eventsent.net/event_lists/3d40ba2a4a10947c17c2337fba3421dd406cceb5.html might be temporarily down or it may have moved permanently to a new web address.
Error 501 (net::ERR_INSECURE_RESPONSE): Unknown error.
Note that the subdomain is staging.app. If you happen to be using Firefox, you get a nice error message the spells everything out:
This Connection is Untrusted
You have asked Firefox to connect securely to staging.app.eventsent.net, but we can't confirm that your connection is secure.
staging.app.eventsent.net uses an invalid security certificate.
The certificate is only valid for the following names:
app.eventsent.net , www.app.eventsent.net
(Error code: ssl_error_bad_cert_domain)
The easiest solution would be to get a WildCard SSL certificate that is valid for *.eventsent.net.
FYI, if you visit https://staging.app.eventsent.net/event_lists/3d40ba2a4a10947c17c2337fba3421dd406cceb5?frame=true, you will get a rather dire-looking warning from your browser. If you ignore the warning and tell the browser to accept the certificate, your Facebook page will then load fine in the same browser.
I am using the facebook SDK for local rails development, and have changed my site URL and canvas URL set to localhost:3000/settings and localhost:3000/facebook/index respectively. After a user authenticate at settings/ they would be redirect to facebook/index
However on either pages I get this message
Given URL is not allowed by the Application configuration.: One or more of the given URLs is not allowed by the App's settings. It must match the Website URL or Canvas URL, or the domain must be a subdomain of one of the App's domains.
This occurs occasionally and not all the times and it causes the facebook SDK (that makes a pop up login) to give the same error message when I tried to log in. I am not really sure what could be causing this, does anyone know why?
EDIT: NVM this is fixed, I found out that fb.js was being loaded twice, bad mistake!