I have developed a CMS using casein plugin. When I run locally (localhost:3000), everything works fine (login, logout, navigation, etc.). When I push to my main site, and try to login, I get this error:
The webpage at http://.com/admin has resulted in too many redirects. Clearing your cookies for this site or allowing third-party cookies may fix the problem. If not, it is possibly a server configuration issue and not a problem with your computer.
I have tried clearing my cache/cookies and no luck. I even tried deploying to dev..com and same issue resides. The weird thing is, if I run script/server on .com or dev..com and go to .com:3000 or dev..com:3000, it works fine and the redirect issue does not exists... Before I post any code, has anyone ever seen this before? For some reason my before_filter is not picking up the session when not running script/server. Any thoughts?
One case that might cause this:
Your authentication mechanism redirects unauthenticated users to root_path
root_path tries to authenticate a user and redirects to the sign in page
Related
I have a rails app with sorcery for authentication. I'm trying to get Stripe checkout integrated but I'm seeing an issue with Safari. Works fine with Chrome and Firefox.
I can successfully create a Stripe hosted checkout page with the cancel url and the stripe js sends me there in the same browser tab. Problem is when I click on the cancel/back link on the checkout page it goes back to my app and punts me to the login page as it can't find the session and current_user is nil.
Funny thing is that on the login page if I simply type in the cancel url into the address bar it authenticates me successfully so it must find the original session/cookie.
Has anyone encountered this? Is it a caching issue? I see no errors in the log nor in the js console. Just this in the server log...
Filter chain halted as :require_login rendered or redirected
And it's nothing to do with Stripe either as I created a simple test.html page on another server and different domain with a link to the cancel url. Same result. I see the same issue going from https back to my localhost server as well as in a staging environment https -> https.
I've also cleared my Safari cache, history, cookies, restarted the browser and my computer and cleared the rails sessions table to no avail. I'm using activerecord session store but also tried with plain cookies.
Any hints/solutions would be appreciated. Thanks!
This is apparently a known bug with Safari as of Feb 19 2021. Safari won't send the cookie if it's set to Lax. Rails 6 defaults are lax now where < 6 is wasn't set.
First in my localhost and then on the live environment Azure Active Directory authentication has stopped working suddenly. It redirects me to the same login/logout page.
I checked for the client id and tenant id they were not changed and they match the ones in azure, it was working fine yesterday just today it stopped.
Sometimes I also get error as Bad request in a plain html.
This is definitely a question regardless of any fixed template of a question you have in mind.
I found the solution. In the azure portal go to the app registration then choose the application and go to authentication and in the redirect uri append this to your website url
/.auth/login/aad/callback
I've implemented mixed mode authentication in our MVC 5 application and everything seems to be working fine apart from one niggly problem.
When I browse to the site in Chrome the following page is displayed:
This site can’t be reached
The web page at xxxx might be temporarily down or it may have moved
permanently to a new web address.
ERR_UNEXPECTED
The main page is actually loaded, but I'm concerned that this might confuse users. The error doesn't appear in Firefox, IE or Edge.
I'm assuming it's down the redirects I'm performing during the login process, but I'm not sure why Chrome is showing the error.
The basic process is:
Forms authentication process checks if user is logged in
If authenticated, redirect to desired page (or default)
If no, redirect to signin action
Signin action then checks if single sign on is enabled, if it is then the user is redirected to an area of the site which can handle windows authentication. Otherwise they are redirected to the normal login page
User is then either authenticated using windows authentication, or redirect to login page
Just looking for any ideas as to why this error is only shown in Chrome
I ran into the same behavior with chrome briefly displaying the above error before loading the page. I narrowed it down to a chrome issue while handling the http2->http1.1 downgrade caused by using windows authentication (HTTP2 doesn't support windows authentication).
I ended up working around the issue by disabling http2 on the server. No real downside in my case since all the sites were behind windows authentication so the connection was always being downgrade to http1.1 anyways.
The following chrome bug has more detail.
I am trying to connect facebooker and authlogic using this http://github.com/kalasjocke/authlogic_facebook_connect
I was having problems so began to debug the facebooker gem code. I realized that no params are getting set using the facebook login that have anything to do with facebook. I can push the facebook login button, it brings up the facebook window as it should and I accept/sign into facebook. Then in facebooker/rails/controller.secure_with_facebook_params! I print out params, this is what shows:
authenticity_token<pulled out token number>actioncreatecontrollerperson_sessions
person_sessions is the name of my user_sessions. Not sure if this makes a difference though...
This is it. Clearly there should be other parameters here. I checked to make sure that my application numbers are all OK with facebooker.yml (although honestly I don't understand why that would matter as I'm not yet making a facebook app, just want to use connect).
Any ideas?? I would be SOOOO thankful if someone could help me out... any clues would be useful!
K
Argh I think I finally figured it out! Since I don't have an app yet then set_asset_host_to_callback_url in facebooker.yml should be set to false. However, after this is done, you have to close browser as it seems to store previous session. Now to fix my next problem!
I had this same issue, my problem was that I had set a Site Domain on my application settings page on Facebook itself... I wasted lots of time fiddling with my code and my settings in my rails app when it was a facebook setting all along. Big up to Alex Neth on the authlogic google group in the end. So what I had was
Application ID 150132505999999
Application Secret e7fb8001d80e99999999999999999999
Site URL http:// localhost:3000
Site Domain localhost
and what I should have had was
Application ID 150132505999999
Application Secret e7fb8001d80e99999999999999999999
Site URL http:// localhost:3000
Site Domain
duh, probably an obvious one but I hope this helps someone out somewhere.
(I've had to break up the site url there for spam issues on this site)
We're experiencing a really bizarre bug in our Rails 2.3.4 app.
This bug only happens in Internet Explorer (7 and 8). Here's what happens:
A new customer creates an account at https://domain.com/signup/free (notice no subdomain)
Their account is identified by a subdomain like "example.domain.com"
After signing up, they get a welcome screen with a link to their account's home page
They follow the link, then click the "log in" button and attempt to login
Even though they provide valid credentials, the app redirects back to their account's root url ... they can never reach their admin area
The only way they can login (on IE) is by quitting and re-opening IE ... then it works fine ...
Something with their initial session is preventing them from logging in. If it matters, we are using restful_authentication and the ssl_requirement plugin ... I'm not sure if one or both of those has a problem with IE but we are stumped here.
Also, I've read IE has an issue with subdomains that contain underscores ... this isn't what's going on.
If the domain of the session cookie is set to 'domain.com', try setting it to '.domain.com' instead.
I don't know if this works with 2.3.4, but
ActionController::CgiRequest::DEFAULT_SESSION_OPTIONS[:session_domain] = '.domain.com'
used to do the trick.