I'm using a Google Login component in my website that calls Google OAuth API. Is it possible to somehow define an IP whitelist together with the domains whitelist?
The expected result is that even if someone successfully identifies with a whitelisted-domain google account, it will still be rejected if their IP isn't whitelisted
When a domain is used on the consent screen or in an OAuth client’s configuration, it must be pre-registered. If your app needs to go through verification, up need to the Google Search Console to check if your domains are authorized.
Domains used for a redirect uri when the app is set to production must also be verified domains.
You cant set a domain as an ip address and you wont be able to set your redirect uri as an ip address either.
Related
Using Google Domains, I've set up a synthetic record to redirect foo.com -> www.foo.com. Just like in this example:
https://support.google.com/domains/answer/6346300?hl=en
However, it doesn't seem to work with https://foo.com.
How do I configure it so that the subdomain forward works with https as well?
To give it more context, I'm mapping my custom domain to a heroku app, so I've set up a CNAME record for www.foo.com, and would like https://foo.com to be mapped to https://www.foo.com
Before providing any input please confirm if you are using any pointing service?
If http://foo.com is working whereas https://foo.com is not then you may need any service like pointDNS or cloudflare.
I am trying to set up google authentication for my local project. I run projects in python virtual environments and have different local domainnames set up for those. Names like projectname.dev. When i enter http://projectname.dev in browser the site opens up.
When i went to https://console.developers.google.com/project/< myprojectid >/apiui/credential?authuser=0 i could set values like javascript origin and authorized redirect uri there. I set javascript origins to http://projectname.dev and tried to put same domain for authorized redirect url too, but it did not work and i had to leave it to localhost.
When i tried to authenticate via django-allauth, i got such response from google:
**Error: invalid_request**
Invalid parameter value for redirect_uri: Non-public domains not allowed: http://projectname.dev/account/google/login/callback/
Now my questions are:
Can i develop this part of project locally with domainname like projectname.dev or do i need to set it up for localhost? Will local redirect from localhost -> projectname.dev work?
If i can do it with projectname.dev, then perhaps there is an error in the way i have this project set up in google developers console?
In any case, if you cannot set the redirect URI in the Cloud Console, Google will throw you our when you try to authorize the app.
My recommendation would be to choose either of those solutions :
Use "localhost" as you said, with some kind of redirection/NAT/proxy to projectname.dev
Replace projectname.dev with a domain with an actual tld such as projectname.thisdomaindoesnotexist.com . Then configure this domain name to map to your servers.
Or wait for ".dev" to be recognized as an actual TLD, and you'll be good :)
I've got an internal web app for my company that uses a login with google authentication system. It's working well for the most part, they can authenticate with google, give consent for my app to access basic user details, and then when they are returned to my app, I can indeed get their user details.
The issue is that I thought once they give consent they wouldn't have to do it each time. Is this an incorrect assumption? As it is now, each time they click the "login with google" they must give consent rather than being redirected back to my app.
I'm using PHP (codeigniter) and a pretty good Oauth lib found on github (fork of phil sturgeon's library). Is there some param I should be passing so the user doesn't have to give consent every time, after the first time?
Google login does not require user consent every time. If you're using OAuth2 Login procedure, you should be able to login a second time w/o re-approvals: https://developers.google.com/accounts/docs/OAuth2Login
In some contexts, however, it is possible for auto-approval to become disabled, with the subsequent requirement of user consent on every login.
The first and most common case is if your application explicitly requests Google to prompt for consent everytime. Check if your authorization request (which you may have copied from an example or sample code) includes 'prompt=consent' or the older, non-standard form 'approval_prompt=force'. Removing these parameters (if present), will likely cause auto-approval to start working.
Another situation is if your redirect URL is based on 'localhost' or some other URL that does not belong to the global DNS namespace. In this case, for security reasons, Google sets a cookie on the user's computer, in the accounts.google.com domain, to signal that the user authorized _this_device_ to login to 'foo' on localhost (or local domain); Google will only auto-approve w/o consent a 2nd request if it finds the cookie. The reason is that the meaning of 'localhost' (or local domain, or other URL not built on global DNS namespace) is device-dependent, and allowing the authorization to apply across devices could introduce security risks. So if your company has configured browsers to clear all cookies on exit, and you use a non-absolute URL, you could see your users having to consent everytime. The solution is either to host your endpoint on an Internet-valid hostname (the host doesn't need to be accessible from outside the Intranet, just the hostname needs to be globally valid), or you need to exempt accounts.google.com from the cookie clearing policy.
Say I have an app with a Sinatra REST API at http://example.com:4567. With my app I have a designer working on the front-end. Rather than set him up with a local back-end I edit his hosts file as follows:
127.0.0.1 local.example.com
and his httpd-vhosts.conf as follows:
ProxyPass /api http://example.com:4567
ProxyPassReverse /api http://example.com:4567
so that API calls are proxied to the remote host. I then create a vhost for local.example.com in apache that maps to his local directory where our front-end repo is. This allows me to give him a remote back-end with a local front-end.
The reason for the subdomain is because we do Facebook authentication which has its restrictive domain policies for auth. We can successfully facebook auth a user and get redirected back to the app, but when attempting to get an access token get a 400 response with the message:
{"error"=>{"message"=>"Missing client_id parameter.", "type"=>"OAuthException", "code"=>101}}
I believe the client_id is correctly set as it's set in the rack:oauth:client object correctly, and the flow is identical and only fails when the domain is different. The only thought I have is that facebook might not like that the user auth's from local.example.com while the access token is requested from example.com, but my understanding is facebook will authenticate on all subdomains. I've also whitelisted local.example.com on my App.
Any insight or advice into how to accomplish this? Thanks in advance.
Turns out it wasn't a domain issue, but rather fb_graph, the open source fb api from nov, uses basic auth by default, you need to set auth to something other than ":basic" when you get the access token in order to solve this error.
I'm building a Sinatra app which needs to use a session variable for one very specific thing. The session variable is set when the user is looking at an SSL enabled page.
I'm using Heroku's piggyback SSL, so the SSL url is something like https://myapp.heroku.com
However, the app itself is hosted at my url, myapp.com
Is there a way to make my session variable, which is set while on the ssl / heroku domain name, available to my app while while on my domain name?
Unfortunately no, since the cookie is tied to the domain. What you'll have to do is either allow authenticated users to use the https://foo.heroku.com domain, and reserve your nice domain for the landing page & other unauthenticated pages.
That, or pay $20 for heroku's SSL add-on.
(I ran into this exact problem in http://appkickstand.com and I chose to just deal with the heroku url for logged in users)
You should look for cross-domain cookies manuals, check this.
But i don't see many reason in setting cookie through secured channel and transmitting it later via raw HTTP, where everyone could sniff it.