Salutations all!
I purchased a Google Domain to make my app slightly more professional than just a bare Herokuapp. I'm running into issues with Oauth2 on that particular branch of the site.
I'm running rails on the back and a bit of react on the front.
I'm not sure what all you'll need, but I'll start with some bits of code and see what comes up.
The Oauth2 works just fine on the herokuapp portion and on localhost.
The error (redirect_uri_mismatch)
My authorized redirect URIs
Again, attempting to login with google on either Localhost or on Heroku works just fine.
You have a comma , after your specified domain name.
It's showing up as:
http://www.stitchinti.me/users/auth/google_oauth2_callback,
It should be
http://www.stitchinti.me/users/auth/google_oauth2_callback
Related
I'm writing very simple application that uses Instagram basic display to show user's pictures uploaded to IG. However, the first step during OAuth authorization, after succesful login/authorization takes user to https://www.instagram.com/ instead of redirect_uri specified in GET parameter of request.
I followed the docs multiple times, tried different IG users, but without any effect.
I'm using this link to authorize user:
https://api.instagram.com/oauth/authorize?client_id=my_instagram_app_id&redirect_uri=https://localhost/api/ig/proceed/&scope=user_profile,user_media&response_type=code
Application settings:
Settings > Basic > Website > Site URL = https://localhost/
Instagram basic display > Basic display > Valid OAuth Redirect URIs = https://localhost/api/ig/proceed/
Roles > Roles > Instagram testers = My account is added and confirmed in instagram settings.
Apache server runs at localhost and acts like reverse proxy (to provide HTTPS, as it's required for all redirect urls).
ProxyPass "/api" "http://127.0.0.1:8080/api"
ProxyPassReverse "/api" "http://127.0.0.1:8080/api"
I have some unrelated records in etc/hosts, but nothing affects this.
Tried this on all browsers I have - Firefox, Chrome, Edge. The weirdest thing is that it worked on FF for the first time, but no matter what I tried to do (annonymous browsing, recreate the whole app in meta devs, remove authorization from user) I wasn't able to reproduce the right behavior.
Another weird thing is that it works fine on safari browser on iPhone, however I cannot display logs or anything, so I have no idea why. And the redirection ends on localhost (which is obviously not running anything).
The whole thing puzzles me gravely and I'm out of ideas why is this extremely simple use of well documented API is broken (probably just for me)
It was probably caused by short term issue with the Instagram authentication API itself. The problem went away after several days, now everything works flawlessly. I didn't have to take any steps to solve it.
I am trying build up a Staging Environment for an ASP.NET MVC Web App, but am stumbling from problem to problem, the last one having been this one: HTTP 500.79 Error / System.UriFormatException when deploying ASP.NET App to Azure Web App
Currently I am getting a HTTP 403 - Forbidden, "You do not have permission to view this directory or page." error when trying to access the page.
Authentication-wise the App uses Azure Active Directory as Authentication Provider, which is working fine in local testing (using a Test-AAD) and in production. The local and productive apps are not using Azure Web Apps. I noticed on the Azure App Service page that there is a possibility to specify authentication right within Azure, but I don't really want / need to use that, as everything is specified within the app resp. configured in the web.config (ClientID, ClientSecret and Tenant). Anyway, when I tried filling in the Authentication on Azure directly it did not work either, so I removed it again.
What happens now is that the redirect to the Login page on login.microsoftonline.com works, and according to the AAD Admin the login attempt is being successful, or at least shows no pecularities. However, when being redirected back to my page, I get a generic 403, without any additional information that could help pin the problem down.
I did check all sorts of logs for further details, and the only pecularity I found is that for some very odd reason, all requests are made to a completely gibberish URL:
Requested URL / specified Reply URL: https:\\skillmanagementtest.azurewebsites.net
Actually requested URL according to logs: https:\\Skillmanagementtest:80
I have absolutely no clue where this URL originates from, however, "Skillmanagementtest" with that capitalization seems to be the name I specified for the Azure Web App:
Screenshot resource group items
The web.config is being transformed properly during the CI/CD pipeline and I double-checked the auth settings there (tenant, clientID, clientSecret), and I am really out of ideas what may be causing this problem.
One hint I found on other problems was to check the IIS logs, but when I attempted accessing the directory these logs were said to be placed in I was rejected access, even though I have owner permissions on the App Service...
UPDATE
After a long and weary process of trying stuff out and discussing we finally got the App up and running. Some observations we made which may be interesting for others with this or similar problems:
The role-based authorization did not work because we forgot to specify the App Roles in the App registration's manifest file, and then link the security groups to the application roles. Check here for more info: https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps
We had one API which is only visible within our company's domain. As an Azure Web App runs outside that domain, trying to access that API resulted in an internal server error. We still have to find a solution for this.
We had a situation where requests to the reply URL after authorization would be redirected from HTTPS to HTTP. We have solved this, but as five people were trying out stuff consecutively we don't know currently what the fix actually was. We may create another Azure Web App which may then reveal this part of the solution.
Check to ensure that what you have in your web.config and app settings matches what you have in the reply URLs for your app registration in the portal. There may be some reference somewhere where the reply URL does not match.
Are you using the openid sample? https://github.com/Azure-Samples/active-directory-dotnet-webapp-openidconnect
Also ensure that you are logging in with a user who has the right permissions under the tenant and to the app itself. My colleague and I made a short video that includes the right configurations that may be helpful for this use case. https://www.youtube.com/watch?v=MohaxN6fsDs
After a long and weary process of trying stuff out and discussing we finally got the App up and running. Some observations we made which may be interesting for others with this or similar problems:
The role-based authorization did not work because we forgot to specify the App Roles in the App registration's manifest file, and then link the security groups to the application roles. Check here for more info: https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps
We had one API which is only visible within our company's domain. As an Azure Web App runs outside that domain, trying to access that API resulted in an internal server error. We still have to find a solution for this.
We had a situation where requests to the reply URL after authorization would be redirected from HTTPS to HTTP. We have solved this, but as five people were trying out stuff consecutively we don't know currently what the fix actually was. We may create another Azure Web App which may then reveal this part of the solution.
I have a RoR app that reads emails from my inbox using the gmail gem. I've deployed to Heroku and everything works fine, except connecting to gmail.
On my local machine it connects with no issues (after I allowed access for less secure apps).
Using the basic gmail login method;
Gmail.connect!('my_email#gmail.com','password')
I get the following error in production only.
Gmail::Client::AuthorizationError: Couldn't login to given Gmail account: my_email#gmail.com (Please log in via your web browser: https://support.google.com/mail/accounts/answer/78754 (Failure))
And then I'll go to https://www.google.com/accounts/DisplayUnlockCaptcha (as other answers have suggested) and it will work fine for a short time period and then suddenly stop working again.
I'm using Ruby v2.4.1, RoR v5.1.1 and the gmail gem v0.6.0 (https://github.com/gmailgem/gmail)
Any help would be great.
Are you deploying to a domain? It could be caused by the fact that:
Heroko will not give you even a range of IP addresses - they can, may and will move dynos between Amazon zones as needs require.
Your only option would be some sort of proxy node with a static IP that they talk to that securely communicates to your Heroku app - or consider if Heroku is the right fit for you here altogether.
Source: Get a finite list of IP addresses for my Heroku App?
It seems like you sign into Google and whitelist what an IP (as far as they're concerned) and then the dyno switches a bit later for whatever reason so then Google no longer has your dyno's IP in the whitelist for this app.
I'm building an iOS app, right now it does nothing, I'm implementing the user registration and login first. There's a couple half-implemented features that interact with the database, I've tested them, they work. But right now forget all the things, let's just focus on having proper registration and login for the application.
The backend is Django 1.9, Django REST Framework 3.3, with Amazon Web Services, using Elastic Beanstalk.
I tried googling all of google, tried using multiple methods (aside from using GMail/Facebook for logging in). Using Django-allauth 0.26 right now, and getting status 403 for both registration and logging in. Registration works when using the browser, but not the mobile frontend. Don't know why.
When attempting to login in the browser, a popup pops up saying that the domain (from AWS Elastic Beanstalk) requires a username and password. Part of me is thinking that this is the culprit, but I don't know where this is coming from. I can't find anywhere in AWS that might cause this to popup. I tried all my usernames and passwords, and none of them work.
Please someone help. My time is running out.
Edit
Just go here. I should've gone through the tutorial like everyone else, but if you happen to get this problem and happen to read this post, you'll find the answer in the official tutorial and API-Guide in the official website (Right next to the tutorial in the navigation bar of the official website, up top. You can't miss it.)
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).