Related
When making an auth request to the Google API (gapi), it's returning false on the checkOrigin.
I have removed any client id's or anything that would link directly to my account and replaced it with a regex indicating what the data is for reference.
Url: https://accounts.google.com/o/oauth2/iframerpc?action=checkOrigin&origin=https%3A%2F%2Flocal.tools&client_id=(\d{21})
My origin url is a local url, which is https://local.tools
Result: {valid: false}
I'm using the example found here without deviation (except for replacing clientid with my 21 digit clientid): https://ga-dev-tools.appspot.com/embed-api/third-party-visualizations/
The items I'm trying to display show up nicely on the demo site, but aren't getting past the Not valid origin for the client error on my local.tools site.
Clear your browser cache. Started getting this error in Chrome and then I created a new client id and was still getting the issue. Opened firefox and it worked, so I cleared the cache on Chrome and it started working.
I received the same console error message when working with this example: https://developers.google.com/analytics/devguides/reporting/embed/v1/getting-started
The documentation says not to overlook two critical steps ("As you go through the instructions, it's important that you not overlook these two critical steps:
Enable the Analytics API [&] Set the correct origins"), but does not clearly state WHERE to set the correct origins.
Since the client ID I had was not working, I created a new project and a new client ID. The new project may not have been necessary, but I'm retaining (and using) it.
Here's what worked:
Create a new project
Add and Enable the Analytics API
Create a new credential - ensure that it is an OAUTH credential (scroll to the bottom of this page for instructions https://developers.google.com/api-client-library/javascript/start/start-js#Setup).
During creation of the credentials, you will see a section called "Restrictions
Enter JavaScript origins, redirect URIs, or both". This is where you can enter your origins.
Save and copy your client ID (and secret).
My script worked after I created the new OAUTH credential, assigned the origin, and used the newly generated client ID following this process.
try clear caches and then hard reload, i had same error but when i tried to run on incognito browser in chrome it worked.
Key Point: Add both http://localhost and http://localhost:port_number to the Authorized JavaScript origins box for local tests or development.
Credentials do not work if API is not enabled. In my case the next steps were needed:
Go to https://console.developers.google.com/apis/library
Enter 'People'
From the result choose 'Google People API'
Click 'Enable'
Creating new oauth credentials worked for me
You probably use Client ID like this: <CLIENT_ID>.apps.google.com
Make sure your client ID is without ".apps.google.com"
For me - I just went here:
https://console.developers.google.com/apis/credentials
Then chose the right project; then choose the credential with the same ID shown in your console error message. When editing the credentials you can add multiple origins to the white list.
After updated Authorized JavaScript origins browser still caching old data, so I need to Empty cache and hard reload then it works
1. Change Authorized origins
2. Open Dev Tool (F12) then right-click into reload button
Clearing the cache on chrome works!
Please find the steps below to clear the cache.
Open dev tools (Right-click on the page and select inspect/ press F12)
Right-click on the chrome reload button while the dev tool is opened. (You will find the option to clear the cache and reload the site)
clearing the cache works for me.
for React developers try to restart the project otherwise it will show the same error again and again.
It was a referrer-policy problem.
This has been such a pain for a long time to me too...
Found the issue, my website instance had a referrer policy set to
no-referrer. After setting it to no-referrer-when-downgrade, the One
Tap prompt showed up as expected.
https://stackoverflow.com/a/63039142/15565029
If you are using Django, SECURE_REFERRER_POLICY is 'same-origin' by default. Change it by adding the below code in your settings file.
# settings.py
SECURE_REFERRER_POLICY = 'no-referrer-when-downgrade'
https://docs.djangoproject.com/en/3.2/ref/settings/#std:setting-SECURE_REFERRER_POLICY
Similar to few answers at above but with screenshots. If you created project for Firebase, may also use the same steps to configure at Google Cloud Platform console.
Select the project at https://console.cloud.google.com/
Navigate to Credentials
Click Edit button for the related OAuth 2.0 Client ID
Add URI into Authorized JavaScript origins
Don't forget to Save
That worked for me after trying for an hour:
On https://console.cloud.google.com/apis/credentials :
Edit Client Outh (mine was: Web Client (Auto Created by Google Service), which was created by my Firebase Web Project)
Enter JavaScript Origin for the Client ID (mine was: localhost:NNNN)
and don't forget to Save.
Try google login for half an hour: didn't work
Enabled Google Analytics as suggested above
Empty Chrome cache and hard reload as suggested above
Try google login for half an hour: didn't work
Sign Out from https://console.cloud.google.com, and sign in again
Empty Chrome cache and hard reload
Now it worked
I don't know which one of the above fixed the problem.
May be it was just a matter of time for cloud.google to
recognize my new JavaScript Origin.
I got the error because of Allow-Control-Allow-Origin: * browser extension.
Trying on a different browser(chrome) worked for me and clearing cache on firefox cleared the issue.
(PS: Not add the hosting URIs to Authorized JavaScript origins in API credentials would give you Error:redirect_uri_mismatch)
I was getting the same error but tried publishing my app and now it shows as below:
I transferred my magento installation on ubuntu with files and mysql db dump to my development machine on Windows 10 with XAMPP installed.
I can up the frontend, but I cannot login my admin backend.
I am sure the password and user name are exactly as my installation on ubuntu, why happened? It just stay on the login form and saying all the time invalid formkey, I viewed the source formkey value just generated there.
There mentioned issue with charset, tried no help.
There is no any error logged in var/report and XAMPP apache errorlog, access_log to /index.php/admin is 200, looks good.
will you have any idea? thanks in advance.
Possible causes include
Incorrect permissions on var/session, preventing session files from
being saved
Incorrect configuration of database/redis/other session storage,
preventing saving of session values
A module is instantiating sessions to early, preventing the correct
session names from being set
The cookie domain in System -> Configuration -> Web -> Session Cookie
Management doesn't match the actual site domain.
You're using the localhost as your server domain, and using a version
of webkit that has trouble/bugs setting cookies for localhost in some
situations.
Easier is just to use the IP-address 127.0.0.1 to access Magento.
Open magento database and run below query.
update `core_config_data` set `value`='/' where `path`='web/cookie/cookie_path';
update `core_config_data` set `value`='[magentohost]' where `path`='web/cookie/cookie_domain';
If you have setup multiple store with subdomains, add Cookie Domain: .magentohost.com
Add a dot “.” follwed by Magento URL.
source : CodePetals
I just move my Magento store to my localhost environment for testing use, I also using Git to maintain code, but after I move all the files to my local environment, I can't login my admin page, but I can still see my frontend pages, and the git, the database, seems works well.
When I type a wrong admin/password to my admin page, it still gives me "Invalid password".
But when I enter the right one, it just refresh the page and stay at the login page, nothing happens.
Does anyone has met this problem before? Has any ideas?
Thanks in advance!
Although this question is old, all the above answers did not work for me until I did one additional thing.
Follow the very helpful answers already posted (summary):
Change your base_url to http://127.0.0.1/ for secure and unsecure path.
delete files in var/session and var/cache
alter your Varien.php file accordingly - depending on your version of Magento.
And then:
Finally, use http://127.0.0.1/your/site/folder/name/index.php/admin
It was the lack of the index.php/admin ( instead of using http://127.0.0.1/site/admin ).
I hope this helps someone else.
Recently started using Magento for a project and came across this issue. I was left frustrated by the fact there are at least ten or more different workarounds suggested on the net and it took a bunch of trial and error to find one that did the job. Seemingly some workarounds work for some versions and not for others. No one explained why or how the problem occurs and the most popular solutions involve hacking the code base or using a different url, which shouldn't be necessary.
The cleanest solution I found for Community Edition 1.9.1.1 was editing two config values in the database:
update core_config_data set value = NULL where path = "web/cookie/cookie_path";
update core_config_data set value = 0 where path = "web/cookie/cookie_httponly";
The cookie path is actually NULL by default on a fresh installation but it must either be NULL or empty string.
The behavior arises because some browsers including Chrome have issues creating cookies with a localhost domain, this means that when Magento calls session_start() the session identifier cookie never gets created and as a result information can not be passed from page to page. The login procedure is actually successful but the next request doesn't know about it, hence why you get redirected back to the login screen. There are no errors because Magento doesn't account for this edge case as a possibility.
If you do not provide a domain value when creating a cookie on localhost then the browser has no problem with it. Unfortunately just setting web/cookie/cookie_path to NULL is insufficient, because Magento's configuration class resolves this as an empty string which is enough for a real domain to be set later in the code:
if (isset($cookieParams['domain'])) {
$cookieParams['domain'] = $cookie->getDomain();
}
This method eventually uses the current HTTP host to resolve a real domain for the cookie, and the browser therefore wants nothing to do with it. However if we disable web/cookie/cookie_httponly then Magento will not perform this additional step, $cookieParams['domain'] is unset and no domain gets passed as a session parameter, thus allowing the session cookie to be created and things to function as they should.
Note that any time you modify the database configuration you must delete the contents of /var/cache/ for the changes to be reflected.
If like me you don't want to have to comment out code, or even make configuration changes, then I created an extension which overrides the getDomain() method shown above and returns null if we are on localhost, this should be somewhat more future proof and result in no collateral damage.
http://www.mediafire.com/download/q39p4k95s5tlght/LocalCookie.zip
Try deleting the contents of the cache folder /var/cache. Clear your browser cookies and try. Also, if you have copied down the database from your server, you may need to manually change the base urls (secure and non secure) as well as the cookie domain in the core_config_data table. Do this manually if you need to. e.g. web/unsecure/base_url with production value of http://www.mywebsite.com/ becomes "http://localhost/"
When ever I have had this it's because of this or cache. Ensure the cache folder is ignored in git hub if it's not already.
1.you need remove the cache
rm -rf var/cache/* var/session/*
2.change the domain form core_config_data
update core_config_data set value="http://127.0.0.1/" where path="web/unsecure/base_url";
update core_config_data set value="http://127.0.0.1/" where path="web/secure/base_url";
do these steps :
1: go through: xampp\htdocs\magento\app\code\core\Mage\Core\Model\Session\Abstract**
2: open **Varien.php file
3: make comment line number from 87 to 104 save it and try to login...
Had the same issue, but the fix was changing DB values:
UPDATE `core_config_data` SET `value` = 'http://127.0.0.1/example/' WHERE `path` = 'web/unsecure/base_url';
UPDATE `core_config_data` SET `value` = 'http://127.0.0.1/example/' WHERE `path` = 'web/secure/base_url';
Then in browser http://127.0.0.1/example/admin
Same problem! I fix my problem after remove/replace static domain in core_config_data Table
web/secure/base_url
web/secure/base_link_url
web/secure/base_skin_url
web/secure/base_media_url
For me, running it on IIS (I know, not officially supported):
Although other suggestions kind of worked I found the best solution was to enter a new A record for me domain like
127.0.0.1 local.example.com
Then in IIS add the binding
local.example.com
to my site and it worked perfectly.
I found there were errors when actually trying to login to the customer account more than admin but believe it still applies.
My Magento web site home page has a redirect loop error. When I try to open it it goes to my old server url and gives the error:
The webpage 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.
When I try to go into admin it takes to me old server admin url without any error.
I down loaded the fresh data base and connected my store to that it works fine but when i connect it my old data base it give same error.
Please advise me.
This isn't an ideal solution, but I was having issues with Magento 1.9.x.
The setup was: Nginx Proxy & SSL Terminator => Apache Webserver
No matter what I did enabling SSL caused a redirection loop. I narrowed the issue down to Magento rather than the Nginx configurations.
It was like Magento didn't know it was receiving a secure connection from Nginx even though the correct headers were set.
The dirty solution was to add some code to the very bottom of index.php within the magento root directory (ie. /var/www/magento) just before the Mage::run... line, like so:
if( isset($_SERVER['HTTP_X_FORWARDED_PROTO']) ) {
$_SERVER['HTTPS'] = 'on';
$_SERVER['SERVER_PORT'] = 443;
}
Mage::run($mageRunCode, $mageRunType);
Wrong permissions can also cause this to happen. So in addition to truncating the var/cache and var/session folders, go ahead and make sure that you have the proper permissions on the app, skin, and includes directories, sub-directories and files. I believe the suggested permission setting is 644. You can do this with a proper FTP client such as FireZilla.
Go to table core_config_data
Update these value to be your localhost url(or whatever url you are providing while installation):
web/secure/base_url //(new url)
web/unsecure/base_url // (new url)
Empty the var folder.
I got it fixed.
I manually deleted my cache i was unable to login in my amdin and it get fixed
My issue was Cloudflare, put it in Development mode and it worked. It was cache related.
Issue: ERR_TOO_MANY_REDIRECTS - redirected you too many times
This issue is related cookie domain name.
For ex: if you already installed Magento 2 in www.example.com, and now you change magento base path to sub domain path like www.subdomain.example.com means, then you need to update your cookie domain entry inside of core_config_data table. You cannot access magento 2 backend so you can use following query to check record exist else use insert query.
SELECT * FROM `core_config_data` WHERE `path` REGEXP 'cookie_domain'
if record exit then update subdomain.example.com to the value column.
else
INSERT INTO `core_config_data` (`scope`, `scope_id`, `path`, `value`) VALUES ('default', 0, 'web/cookie/cookie_domain', 'subdomain.example.com');
Then flush cache using command php bin/magento cache:flush
Refresh magento 2 admin, now you can access admin. try this. thanks.
Note: if you are not using cookie domain, then don't configure this settings, if you configuration wrong then also you can face this error, so to fix that error update value to default configuration.
I had the same issue and after reloading and reloading my page I noticed that the error message responded to www.mydomain.tld and sometimes to mydomain.tld. I'm using Plesk on the server and I remembered that I set the Domain to always be called without www. I just changed that to none in the hosting settings of the domain. Lucky me, that solved that issue. Hope that helps someone else.
I have magento installed in a subdirectory. www.domain.com/subdir/magento
This site worked perfectly at one point. I changed nothing, until my client said he couldn't login to magento admin.
I logged in just fine from my computer, but on his computer it just redirected back to the magento admin login without an error message and a url that looked goofy like this:
http://domain.com/subdir/magento/index.php/admin/index/index/key/3097210b826ac4a86d7531cb4089c9d0/
I thought that his cookies were being blocked, but that was not the case.
My magento settings were secure/unsecure baseurl: http://domain.com/subdir/magento/
web cookie path: (blank)
web cookie domain: (blank)
After clearing out var/cache, I found that I myself could not login to the admin either, with the same exact issue.
I tried the following settings without luck:
path: /
domain: domain.com
path: /subdir/magento
domain: vigrond.com
I also tried commenting out those lines in Varien.php, but that had no effect either.
My server account is a VPS and it has plenty of free space.
So I'm pretty much lost, wondering why this happened in the first place when it worked before (didn't change anything), and why it's so complicated?
Any help appreciated
If a login error message ("invalid password", etc.) isn't being displayed it's almost always a session cookie problem. In order to rule it our entirely, use Use your browser's cookie viewer and/or your favorite HTTP traffic sniffer and check
That all the cookies have proper expiration dates after being set
That the session cookie has a consistent token name/value for each request
That PHP, when running through Magento, has the various session lifetime ini settings at a reasonable value
That PHP can write to whatever it's using as a cookie storage medium
That the server's time matches the real time, and that PHP itself has a timezone set
Find app/code/core/Mage/Core/Model/Session/Abstract/Varien.php. in your Magento install folder. Comment out the lines (see below) 80 to 83. The line number may vary.
// set session cookie params
session_set_cookie_params(
$this->getCookie()->getLifetime(),
$this->getCookie()->getPath()//,
//dependes which versin of mage you are using, you may comment these as well
//$this->getCookie()->getDomain(),
//$this->getCookie()->isSecure(),
//$this->getCookie()->getHttponly()
);
This is caching issue. Which recently Magento community confirmed that is sorted but it is not. :)
Just clear your cache and do this steps it should work anyway.
Comment this lines also
// if (!$cookieParams['httponly']) {
// unset($cookieParams['httponly']);
// if (!$cookieParams['secure']) {
// unset($cookieParams['secure']);
// if (!$cookieParams['domain']) {
// unset($cookieParams['domain']);
// }
// }
// }
//
// if (isset($cookieParams['domain'])) {
// $cookieParams['domain'] = $cookie->getDomain();
// }
Make sure you have cookies enabled in your browser, try a number of
different browsers including Safari or Opera. Chrome will give some
problems and you need to remember to clear you cache in Chrome after
making changes!
Make sure you file permissions are set to EVERYONE - FULL CONTROL for Windows and 777 for your Mac/Linux environment If all that still doesn’t work you can try this: (I do not recommend this solution for a production version of Magento, but for you local test enviroment this will work.)
Check the version of php you are using. If you are using recent Magento try to find which version of PHP and extensions requires.
More details
Did you erase the session storage in var directory?
In my case, when I was playing with autorization for multistore on subdomains (changed path and domain for cookie as you did), this method helped me to drop the "bad" cookie and sucessfuly logined in admin:
In apppath/var/session directory I've made command in shell (be careful with path, this could delete all the files in the directory)
rm -rf /path/to/magento/var/session/*
And then just clean the cookie for domain in browser.
I was fighting with this issue today on my local server. I couldn't login using any browser. I really didn't want to comment out any lines in core files or doing any other "dirty" solutions.
Firstly I checked cookie set by browser. It had expiration set to 1970, so clearly it was a cookie problem.
I checked values for cookies in magento database. In phpmyadmin I found table core_config_data, then fields with values : web/cookie/cookie_domain and web/cookie/cookie_path. They were both blank.
My solution was to set:
web/cookie/cookie_domain to my domain name
and
web/cookie/cookie_path to /.
Example:
your domain where you run magento is magento.local
set:
web/cookie/cookie_domain = magento.local
and
web/cookie/cookie_path = /
I never resolved the issue. But I wiped the clients computer and reinstalled windows 7, and it worked. It was very strange that it didnt work before as he was not behind a proxy, did not have ad ons or viruses. And the issue reproduced in each of his browsers (chrome firefox and IE). It was not a router issue. It was a windows issue, but I couldn't tell you what exactly was causing it. It was not the internet security settings either, as I checked those. Also checked the host file. As I said before, very baffling
I had the same problem, but I was working on XAMPP on windows 7 x64.
In Magento system - configuration - web - session cookie management change Use HTTP Only to no and Cookie Lifetime to 86400.
I only changed the Cookie Lifetime just in case of daylight saving time may not have to be changed.
Before the changes I could only login using Firefox and after the changes all browsers work.
Leave Cookie Path and Cookie Domain blank.
Check the cookie configs in core_config_data table and check if your session is being saved on db. In my case, someone just changed the cookie domain and the cookie path with a wrong value.
You can also check this on the node in your app/etc/local.xml.
If it's on db, maybe you should change do files to be able to clean the session data directly on var/session dir.
Delete cookies (related to your domain) from your browser setting.
I was facing the same issue and at the end i found that it was due to full disk space and due to this Magento was not able to create sessions file in the var var/session folder. After cleaning up log files that issue was resolved.
Also, you can update the password in the database if everything else from above didn't work and you need desperate access:
UPDATE admin_user SET password=CONCAT(MD5('qXpassword'), ':qX') WHERE username=‘user’;
replace user and password words according to your needs.
If nothing works, make sure the disk quota is not exceeded. The new session cookies created under ./var/session will be zero bytes length if disk quota for the user is exceeded.
In Case, that you dont see any cookie named "frontend" or "adminhtml", when you reload the page, the Magento cookie wasn't set. In my case I have a wrong cookie_domain.
I used "null" instead of "NULL".
As I set my cookie_domain to NULL in core_config_data, the problem was solved