I have a Rails application hosted on Heroku and I am preparing to deploy another application that will use the same session cookie. Let's assume that main application is hosted at app.mycompany.com and the new application will be hosted at reports.mycompany.com. I've setup session cookies in both apps with cookie domain .mycompany.com and everything works ok. I've modified /etc/hosts to test those settings on my local machine.
Since everything worked fine on my local machine I wanted to test it on our staging environment, which is hosted at mycompany-staging.herokuapp.com. For this app I've set cookie domain to .herokuapp.com. And now it does not work. It is not possible to login. From inspector it looks like correct Set-Cookie header is sent from the server, but the browser never send this cookie back on request.
The same thing happens on my local machine when pointing mycompany-staging.herokuapp.com to 127.0.0.1. This happens only when I use herokuapp.com. Everything else works fine or at least couple of different domains work fine, including herokuapp2.com.
I am really confused. It looks like there is some cache issue, but I don't know where exactly. I am testing this mostly on Chrome with incognito mode, but I also tried Safari with the same problem.
Can anyone point me in the right direction? Or maybe I am missing something obvious.
This is because herokuapp.com is included in the Mozilla Foundation’s Public Suffix List. Cookie with domain *.herokuapp.com cannot be set any more. Refer to doc in devcenter.heroku.com:
herokuapp.com is included in the Mozilla Foundation’s Public Suffix List. This list is used in recent versions of several browsers, such as Firefox, Chrome and Opera, to limit how broadly a cookie may be scoped. In other words, in browsers that support the functionality, applications in the herokuapp.com domain are prevented from setting cookies for *.herokuapp.com. Note that *.herokuapp.com cookies can currently be set in Internet Explorer, but this behavior should not be relied upon and may change in the future.
Related
I've an ASP .NET MVC4 application that uses SimpleMembership and allows users to sign in with their google accounts.
In order to do that I configured the application's AuthConfig class by uncommenting the OAuthWebSecurity.RegisterGoogleClient(); line to add google as an external login method. I didn't really change much inside the external login methods that already come with the ASP .NET MVC4 Internet Application template.
Problem:
Everything works fine when I run it locally (IIS express) or when I deploy it to a 'test' server (IIS 6.1, accessible on the intranet only). When I click my "sign in with google" button, I'm sent to google's authentication page, whose url looks something like this:
https://accounts.google.com/ServiceLogin?service=lso&passive=12096...(long url)
Alas, when I deploy it to the 'production' server (internet facing) and try to access it via internet, Google authentication stops working: when I click my "sign in with google" I'm being sent to an url that looks like this:
http://MY_APPLICATION_NAME.MY_DOMAIN.com/accounts/o8/ud?openid.claimed_id=http%3A%2F%2Fspecs.openid...(long url)
This url is wrong not only because it has my domain in it (I believe it should be accounts.google.com?), but also because the rest of it is completely different from the url I get when the authentication works.
What I know and have tried:
If I use fiddler, I can see that the application is behaving differently when I'm accessing the application via internet or intranet.
If I access it from within the network, I see I'm making a request to http://MY_APPLICATION_NAME.MY_DOMAIN.com/account/ExternalLogin?returnUrl= and then "Tunnel to www.google.com:443, Tunnel to accounts.google.com:443". This works ok.
If I access it from the internet I see I'm making a request to http://MY_APPLICATION_NAME.MY_DOMAIN.com/account/ExternalLogin?returnUrl= and then another one to http://MY_APPLICATION_NAME.MY_DOMAIN.com/accounts/o8/ud?openid.claimed_id=http%3A%2F%2Fspecs.openid...(long url). This obviously gives a 404.
I might be wrong but I assume that this url is generated by the OAuthWebSecurity.RequestAuthentication(provider, returnUrl). What puzzles me is that it looks like it is requesting the authenticaton to my server instead of accounts.google.com.
My research so far has only brought to me posts/questions/etc. showing how easy it is to use SimpleMembership for external authentication and I can see everyone does it pretty much the same way.
Conclusion:
I believe this probably has something to do with something I must configure on web.config or IIS. I do know that the requests to my application arrive at my DNS server which does a url rewrite and forwards the request to my web server, although I don't know if this is related to the problem.
Does anyone have any idea of what might be wrong or ever had a similar issue? Any help would be appreciated.
EDIT:
I've looked into OpenAuthSecurityManager.cs's source code and although I can't debug it I see the problem might be related to an incorrect HttpContext inside the RequestAuthentication method, due to my reverse proxy settings on IIS?
I ended up with a request to change the IT infrastructure.
OpenAuthSecurityManager.cs was probably getting a wrong HttpContext instance because of the way the requests were being handled by the previous infrastructure (requests arrived at our DNS server and were forwarded to the web service, on a different server inside our network, with UrlRerwrite rules).
It's working now.
I changed my CNAME Records as outlined in this link https://devcenter.heroku.com/articles/custom-domains. The redirect itself works, the issue is in Chrome (and I assume other browsers) It gives me a phishing alert.
This is probably not the site you are looking for!
You attempted to reach app.grewpr.com, but instead you actually reached a server i identifying itself as *.herokuapp.com. This may be caused by a misconfiguration on the server or by something more serious. An attacker on your network could be trying to get you to visit a fake (and potentially harmful) version of app.grewpr.com.
You should not proceed, especially if you have never seen this warning before for this site.
How would I fix this error? It also puts a red line through the https lock.
Since you're using HTTPS, you should follow slightly different DNS configuration instructions: https://devcenter.heroku.com/articles/ssl#configuredns
Had the same problem. Your custom domain app uses your host certificate. Whether buy SSL addon or if 'http' is ok for you then change ssl settings for your app. In "environments/production.rb" there must be following configuration "config.force_ssl = false" which by default is set to true. Had to reset Firefox to take effect. Other browsers were ok.
In one of my MVC3 web applications I have recently noticed some strange looking Urls in the analytics reports.
The Urls look like they have an encoded value injected into the route but seem to match the routes as if the encoded value was not there.
Normal Url
/MyWebsite/Controller/Action
Appears in the logs occasionally as
/MyWebsite/(F(B5l-uGhiwA7p6lMmAdzwc27qHH8p5Kdmy5l3ixub7-meZ315Xm-uOtFl_w8RRdki4pf_yhRysEOVZ93xPV3yxDkn5XhXaY5PLara_kiqFb8BlHDZkzqv6wHgOgMTWgUF0))/Controller/Action
I have tested this on the server and local machine and it resolves to the controller regardless of the presence of the inserted value.
They appear to follow a certain pattern so I tested using other variations
/MyWebsite/(F(anything-here))/Controller/Action
Resolves fine, I can also replace the F with any other letter
/MyWebsite/(A(anything-here))/Controller/Action
However, putting more than 1 letter or other character in place of the F does not resolve
/MyWebsite/(AB(anything-here))/Controller/Action = 404 Error
I thought it may be something to do with Cookieless sessions but the information I have found suggests that this isn't supported in MVC anyway. Does anyone know what this is, or if it is anything to worry about?
EDIT:
Turning off cookies for a local browser, I set the session state to 'Auto Detect' in IIS manager and it gave me a key in the URL that looks strikingly similar to the pattern described above.
When I try to actually log in without Cookies it doesn't seem to work, but perhaps that's another issue.
Setting IIS manager to 'Use Cookies' and accessing using a browser with cookies turned off (I used Opera with option 'Never accept cookies' in Advanced preferences) didn't seem to create the URL as before, but judging by the similarities it must at least explain why it matches the routes.
Since IIS is set to 'Use Cookies' on my server, I'm not sure why the URLs are being generated, but at least I now know what they are. Perhaps this is an attempt at Session hijacking...
This does indeed look like session data stored in the URL. It's a feature of ASP.NET and works just fine with MVC as well. Look in the IIS manager for the Session State icon of your website and it's Cookie Settings Mode is most likely set to Auto Detect. This might cause it to fall back to URI mode in case cookies are not supported.
I can't figure out what I'm overlooking, perhaps it's obvious or lack of understanding.
The app I'm working with uses subdomains which on the hosting server work properly. I figured locally installing would kick up some issues around routing, so I read up on making changes to /etc/hosts and using the Ghost gem. Both seem to work fine i.e. localhost:3000/ becomes myapp.local:3000 but I don't understand how to go about logging into a subdomain account. Here's an example...
myapp.local:3000/session/new = the default login page for the app
myapp.local:3000/signup = default signup page
I can create an account here e.g. Sub1
The thank you page is shown w/ the reference to sub1.myapp.com which points to the hosted app (the local db shows this domain as well)
sub1.myapp.local manually added to /etc/hosts and dscacheutil -flushcache
sub1.myapp.local:3000/session/new is the subdomain
login attempts return that this isn't a valid domain. This seems to make sense because the local db shows the url as sub1.myapp.com on the hosting server.
So my question is whether there's a local workaround that I can use for development or have I totally missed a fundamental concept along the way?
you might just want to try putting the actual dot com in your /etc/hosts file.
ie:
127.0.0.1 sub1.myapp.com
127.0.0.1 myapp.com
127.0.0.1 anyothersubdomains.myapp.com
what this usually does is trick your computer into thinking it is the host of all of those, so you can't go to the real site anymore in a web browser.
if you do want it to be .local, presumably so that you can refer to the real online site while working on a local copy, you should probably take a look in app/controllers/application_controller.rb (sometimes application.rb) and look for logic in there that helps determine what to do depending on the subdomain. maybe its hard coded to only look for a .com or something.
If you are using the webrick server or something like Puma for development you can use lvh.me to access your subdomains. e.g.
http://sub.lvh.me:3000/
http://lvh.me:3000/ is equal http://localhost:3000/
One of my rails apps (using passenger and apache) is changing server hosts. I've got the app running on both servers (the new one in testing) and the DNS TTL to 5 minutes. I've been told (and experienced something like this myself) by a colleague that sometimes DNS resolvers slightly ignore the TTL and may have the old IP cached for some time after I update DNS to the new server.
So, after I've thrown the switch on DNS, what I'd like to do is hack the old server to issue a forced redirect to the IP address of the new server for all visitors. Obviously I can do a number of redirects (301, 302) in either Apache or the app itself. I'd like to avoid the app method since I don't want to do a checkin and deploy of code just for this one instance so I was thinking a basic http url redirect would work. Buuttt, there are SEO implications should google visit the old site etc. etc.
How best to achieve the re-direct whilst maintaining search engine niceness?
I guess the question is - where would you redirect to? If you are redirecting to the domain name, the browser (or bot) would just get the same old IP address and end up in a redirect loop.
If you redirect to an IP address.. well, that's not going to look very user friendly in someone's browser.
Personally, I wouldn't do anything. There may be some short period where bots get errors trying to access your site, but it should all work itself out in a couple days without any "SEO damage"
One solution might be to use Mod_Proxy instead of a rewrite to proxy traffic to the new host. This way you shouldn't see any "SEO damage".
I used rinetd to redirect the IP traffic from the old server to the new one on IP level. No web server or virtual hosts config needed. Runs very smoothly and absolutely transparent to any client.