I'm trying to login to a fresh Typo3 v11 copy but login don't work.
to reproduce this issue:
Setup a fresh install Typo3 v11, i put my login and password in backend.
after click on login it load for 1sec then stay in same page. nothing happen, just keep showing the login form.
I have re-installed the project and copy the .htaccess file from the install source code but this didn't help.
TYPO3 probably misses your cookies.
either you have redirecting (e.g. http to https or another domain)
or you have restricted the IP ($GLOBALS['TYPO3_CONF_VARS']['BE']['lockIP']) and switch the IP because of proxy or loadbalancer.
I have deleted cookies for this website, now login works. probably the browser still keeps old website cookies.
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.
I recently downgraded one of my Heroku apps to a free dyno - as a result, the SSL was revoked (cos I was using the SSL provided with a paid dyno). Now, when I visit my site URL, it gives me this error: ERR_SSL_PROTOCOL_ERROR
I've edited my production.rb file to set: config.force_ssl = false and published that code, but it still redirects my site to https when I try to connect on http.
Now, to complicate things:
This only applies to my custom domain - the .herokuapp.com domain works fine
It works fine on incognito mode on both the custom domain and the herokuapp.com domain
I've tried clearing the cookies and cache (for the last 7 days) and it still didn't work :/
Any ideas what I can do?
Edit:
In case it helps, I am using Chrome on Windows 10
Given that you are using Chrome, according to this answer, you need to follow these steps to stop Chrome from redirecting http:// to https://.
Anon is right about STS, but there is a way to specifically delete your domain from the set. Go to chrome://net-internals/#hsts. Enter 3rdrevolution.com under Delete domain security policies and press the Delete button.
Now go to chrome://settings/clearBrowserData, tick the box Cached images and files and press click the button Clear data.
How do I test the Google OAuth 2.0 on my app with localhost, since Google requires a top private domain as the authorized domain?
I tried to look up solutions, but all the solutions given have been a while ago, and I think Google has changed their service since then.
localhost is not a valid top-level domain, and it won't let you generate credentials without setting up a consent screen. You can add more than one authorized domain if you'd like, but you can't leave it empty. But you CAN delete the field if you have no domains / would not like to add domains for now. you just can't LEAVE it empty.
Notice the description -- "When a domain is used". so it's not an obligation to add authorized domain for consent screen. Moreover, the authorized domain here is only related with consent screen. Authorized origins and Authorized redirect URLs needs to be specified in the credentials part, which is all that matters; specifying the origin from which requests will be accepted and where it will be redirected. So just omit the authorized domain in the consent screen.
So how to delete it? Just in case if you haven't noticed, just hover over the field and this little man will pop up. delete it. that's all. Now you should be able to save and continue, where it might ask you to setup scopes.
I know it's really late, hoping it might help others..
After about an hour banging my head against the wall I found this article that has a step by step solution that works (as of July 2020).
Basically you need to create a service account, share the sheet with that account, and then it should work.
All of the other auth methods I tried either raised nonsense errors, or simply silently didn't work.
The list of authorized domains is required before you submit a request for app verification. If you want to configure a localhost redirect URI, that is configurable in your web OAuth client ID configuration.
In case anyone has struck out on the suggestions above, this answer did the trick for me. Set my authorized JavaScript origins URI to http://localhost:8080 in the google API console then emptied my Chrome cache.
Just add an OAuth-consent-screen from here without a domain or valid domain that's up to you, after that create Credentials from here, then select OAuth client ID and enter your from here you can add javascript origin url and there you go you've done.
You add your final domain for when you are ready to become verified. Until then you will generate an OAuth client ID and enable https://localhost:3000 in "Authorized JavaScript origins"
Simple screenshot of the field you can enter localhost
Not beautiful, but works!
I've made local website(domain) on Xampp like test1.com, added that domain in Authorized domains and started Chrome from separate shortcut with parameter --ignore-certificate-errors
Note, that when you start with this flag, Chrome must not be running!
It cause Chrome to open web site in the xampp\htdocs folder and I was forced to go to folder test1.git and then to public folder, where finally site opened and the url was: https://test1.com/test1.git/public
ps. Use port 80 in httpd-vhosts.conf and not 443!
I created a draft application in my store panel, I added the auth callback and load urls, but when I click to install it, it does not call the oauth url. It's not https, is this a problem, considering it's a draft application?
We're using a draft application and calling localhost, which is obviously not https and it is working fine. My advice is the problem is probably at the server you have instructed Bigcommerce to point to. Try to access that URL manually or use a service like hurl.it to create the request manually.
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