I'm working on a web application which actually consists of two applications under the hood. One application is called account and handles all things related to user accounts such authentication, registration and management of the account. I also have an application we'll just call web.
The thing is that account listens on https://account.domain.com using SSL/TLS, and web listens on http://www.domain.com.
What options do I have for having people log in and authenticate account.domain.com and then redirecting them to www.domain.com where they're actually then logged in. As far as I know, you can't set up a cookie on account.domain.com and then have it work on domain.com as that would be a security risk.
Some background details about my applications:
Written in the Go programming language.
Makes use of the Gorilla Toolkit for most of the HTTP/HTTPS interfacing, URL routing and handling POST/GET parameters.
Both applications live on the same virtual server.
What I'm looking for is a secure way to authenticate and manage a session across all subdomains of and the actual domain domain.com. I'm not particularly well versed in this subject, so aside from setting cookies, I don't know much.
I'm not familiar enough with gorilla but something like should work:
var store = sessions.NewCookieStore([]byte("something-very-secret"))
func init() {
store.Options = &sessions.Options{
Domain: "domain.com", //this
HttpOnly: true,
}
}
Basically you just have to set the cookie's domain to .domain.com (with the prefix .), there's a more detailed explanation in https://stackoverflow.com/a/1063760/145587
//edit
According to #Volker, the dot isn't needed (see comments).
Related
I'm developing a database backed web-app. I will be providing the same basic services to several branches of the same company.
Right now I have an Apache server with virtual servers and a resource server for reporting.
branch1.mycompany.com
branch2.mycompany.com
resources.mycompany.com
So basically when I call resources from the site I pass the site as a parameter.
branch1.mycompany.com -> resources.mycompany.com?branch=1¶meter=1
branch2.mycompany.com -> resources.mycompany.com?branch=2¶meter=1
Even with two branches there is a problem trying to keep up with updating both sites and now, I'm going to be implementing this scheme for seven sites.
So my question is this: Is there a way I can make a IIS or TomEE web-app with the following features?
I want to still allow each branch to access trough its URL
Even when there are 7 URLs; all of them will be pointing to the same web-app
Depending on the URL, is there a way the site parameter can be inferred or calculated so I can call the right resource or web service?
The user should never realize they are accessing a common web-app. (i.e. should not be redirected to web-app.mycompany.com?site=1.)
Tomcat (so tomee) has now a rewrite valve which is close to httpd mod_rewrite, this can surely solve that smoothly. I assume IIS has it as well but don't know it that much. Trick is to reverse proxy the requests.
I'm trying to set a web service that needs the user's Google Latitude info, so I'm using Google OAuth to get the user authorization stuff.
However, when trying to set the redirection URI in the Google APIs Console for a web application client ID I get a message error if I try to set it to 'http://PUBLIC_IP/'.
I need to test it with non local users (thus localhost can't be used), so I would like to know if having a web domain is mandatory in order to use Google's OAuth. If not, how can I solve this issue?
This is not currently supported. I filed a feature request and will update on progress.
Update: Essential app verification activities have continued to make support of IP address-based apps unlikely. These verification activities are necessary to provide protections against abuse of user accounts. In addition, the cost of setting up dedicated domains has been reduced significantly since this feature was requested. Please read other responses here about possible options.
You can use xip.io to work around it.
For example: '192.168.0.50.xip.io:3000' will resolve to '192.168.0.50:3000'
I ran into this issue too and so I entered a URL with a .com extension and also entered it into my /etc/hosts file. Works like a charm.
It totally sucks that my entire app now has to be developed on an apparently 'live' domain though.
I used my public hostname. It helps if you have a static IP address. I used http://www.displaymyhostname.com/ to get my hostname. I plugged it straight into the Authorized JavaScript origins field when I created a new Web Application Client ID.
P.S. My hostname looked something like this: 111.111.111.111.static.exetel.com.au
You can use a dynamic DNS. I used ddns.net which offers a free solution. Basically, you enter your FQDN as this: yourcompany.ddns.net as your domain. When looked up for an IP address, the .net domain points to ddns; when ddns.net is looked up, it looks up in its database for your company, returns the IP. So mine looks like this: https://wigwam.ddns.net and everything works fine. You don't need to buy a domain, you can substitute your known IP, and Google is happy with that.
Your IP must be static, of course.
Yes, as of now you still need to have a domain name to use Google OAuth in your application. If you have a static public IP and don't want to buy a domain name, you could use a free subdomain from FreeDNS to link to your public IP. Seemed to work well enough for me with a Django app.
Echoing what Breno said in response to his earlier comment:
Apologies for the lack of updates here. Essential app verification activities have continued to make support of IP address-based apps unlikely. These verification activities are necessary to provide protections against abuse of user accounts. In addition, the cost of setting up dedicated domains has been reduced significantly since this feature was requested. Please read other responses here about possible options.
You can read more about Google's app verification requirements [1] and Google's policies requiring secure handling of data [2].
[1] https://support.google.com/cloud/answer/9110914?hl=en
[2] https://developers.google.com/identity/protocols/oauth2/policies#secure-response-handling.
xip.io is not working anymore as an alternative you can use nip.io the same way for example:
10.0.0.1.nip.io:8000 will resolve to 10.0.0.1:8000
It seems like xip.io is down, but there are alternatives such as sslip.io and nip.io. However, I couldn't get either of these to work.
I ended up hosting the main file server on the main machine, and ran said server on a 192.168.1.xx IP address. I then ran servers on each of the test machines (including a second server on the main machine), all of which were on the localhost address. Any requests that the localhost servers received were then passed off to the 192.168.1.xx server, which allowed testing on all of the devices.
This should also work with public facing IP addresses.
I'm trying to set a web service that needs the user's Google Latitude info, so I'm using Google OAuth to get the user authorization stuff.
However, when trying to set the redirection URI in the Google APIs Console for a web application client ID I get a message error if I try to set it to 'http://PUBLIC_IP/'.
I need to test it with non local users (thus localhost can't be used), so I would like to know if having a web domain is mandatory in order to use Google's OAuth. If not, how can I solve this issue?
This is not currently supported. I filed a feature request and will update on progress.
Update: Essential app verification activities have continued to make support of IP address-based apps unlikely. These verification activities are necessary to provide protections against abuse of user accounts. In addition, the cost of setting up dedicated domains has been reduced significantly since this feature was requested. Please read other responses here about possible options.
You can use xip.io to work around it.
For example: '192.168.0.50.xip.io:3000' will resolve to '192.168.0.50:3000'
I ran into this issue too and so I entered a URL with a .com extension and also entered it into my /etc/hosts file. Works like a charm.
It totally sucks that my entire app now has to be developed on an apparently 'live' domain though.
I used my public hostname. It helps if you have a static IP address. I used http://www.displaymyhostname.com/ to get my hostname. I plugged it straight into the Authorized JavaScript origins field when I created a new Web Application Client ID.
P.S. My hostname looked something like this: 111.111.111.111.static.exetel.com.au
You can use a dynamic DNS. I used ddns.net which offers a free solution. Basically, you enter your FQDN as this: yourcompany.ddns.net as your domain. When looked up for an IP address, the .net domain points to ddns; when ddns.net is looked up, it looks up in its database for your company, returns the IP. So mine looks like this: https://wigwam.ddns.net and everything works fine. You don't need to buy a domain, you can substitute your known IP, and Google is happy with that.
Your IP must be static, of course.
Yes, as of now you still need to have a domain name to use Google OAuth in your application. If you have a static public IP and don't want to buy a domain name, you could use a free subdomain from FreeDNS to link to your public IP. Seemed to work well enough for me with a Django app.
Echoing what Breno said in response to his earlier comment:
Apologies for the lack of updates here. Essential app verification activities have continued to make support of IP address-based apps unlikely. These verification activities are necessary to provide protections against abuse of user accounts. In addition, the cost of setting up dedicated domains has been reduced significantly since this feature was requested. Please read other responses here about possible options.
You can read more about Google's app verification requirements [1] and Google's policies requiring secure handling of data [2].
[1] https://support.google.com/cloud/answer/9110914?hl=en
[2] https://developers.google.com/identity/protocols/oauth2/policies#secure-response-handling.
xip.io is not working anymore as an alternative you can use nip.io the same way for example:
10.0.0.1.nip.io:8000 will resolve to 10.0.0.1:8000
It seems like xip.io is down, but there are alternatives such as sslip.io and nip.io. However, I couldn't get either of these to work.
I ended up hosting the main file server on the main machine, and ran said server on a 192.168.1.xx IP address. I then ran servers on each of the test machines (including a second server on the main machine), all of which were on the localhost address. Any requests that the localhost servers received were then passed off to the 192.168.1.xx server, which allowed testing on all of the devices.
This should also work with public facing IP addresses.
I am trying to add OAuth athentication with to access YouTube, but how do I add localhost as domain?
For example on domain registration page here, I want to use localhost, since I am developing this application locally.
Please help me or suggest me alternative ways
Thank you
P.S. I also added this question on https://webapps.stackexchange.com/, but not sure about community activity there so please ignore
Obviously you can't register 'localhost' for authentication since it is merely an alias. If you want to use OAuth with any Google service, you'll have to have a domain. If you're developing a desktop app, there is a workaround (this may actually work for all but I didn't try):
You can actually sign your OAuth requests without registering your domain with Google by creating a signature using HMAC-SHA1, a consumer key of "anonymous" and a consumer secret of "anonymous". Just make sure you have the appropriate signature base string for your requests.
http://code.google.com/apis/accounts/docs/OAuth_ref.html#SigningOAuth
On the page in Google's APIs console where you provide redirect URIs for your app, you can use localhost. Or you can give another name to localhost in your /etc/hosts file like this:
127.0.0.1 localhost myname.madeupdomain.net
I have a domain and a group of sub-domains that require authentication to access. I am currently using mod_auth to authenticate users (mod_auth basic) at the domain.tld level. My goal is for single sign-on between the domain and all the sub-domains.
Will these credentials carry on to the sub-domains automatically, or with a simple vhost config change, or is there a better method to do this?
mod_auth_basic
Browsers distinguish areas that require HTTP authentication by a combination of the URL root and the name of the authentication realm.
Take for example, two domains each with a realm with the same name:
http://one.example.com/ with the realm "Please enter credentials!"
http://two.example.com/ with the realm "Please enter credentials!"
First a user visits one, is asked for credentials and enters them. Then the user visits two, the browser recognizes that the URL is different and thus asks again the user for her credentials.
This is a good thing, because otherwise www.badguy.com could set it up so that your browser sends over your online banking login.
In short: there is no way to solve your problem with basic HTTP authentication and standard HTTP clients.
mod_auth_digest
You could use mod_auth_digest instead, since with that you can specify more than one URI to be in the same "protection space". However, with this authentication method there are two new problems:
It doesn't scale very well, because you cannot use wildcard domains.
Browser compatibility is not as good. (See the documentation on how to make it work with IE.)