I can't access the Datastore Admin tab due to a "This webpage has a redirect loop" error and I can't figure out what I'm doing wrong or have set up wrong.
I have Datastore Admin Enabled in my web console.
I've added (although I don't know if this is even necessary):
builtins:
- datastore_admin: on
I've cleared cookies, etc.
Authentication Options is set to Google Accounts API
Has anyone else seen this or know how to fix it?
The issue is being discussed here and I am going to answer it.
http://code.google.com/p/googleappengine/issues/detail?id=4233
First a question. Which browser is this on?
I've had this problem on chrome and it's related to Chrome blocking third-party cookies, over-all a nice thing for it to do. You can add an exception to your third-party cookie settings to make fix the problem.
You need to go to the Chrome settings page. You may need to expand an option called Show advanced settings...
Then look for:
Privacy / Content settings...
Cookies / Manage exceptions...
Then add an exception at the bottom of this list. The exception should look like this:
https://ah-builtin-python-bundle-dot-latest-dot-[YOUR_APP_ID].appspot.com/_ah/datastore_admin/*
Related
It seems keeping all the browsers happy is a challenging task, what with all the security they are adding and the complexities of certificates.
I have a SPA (Vuejs) which is using oidc-client.js to implement OIDC, communicating with an Identity Server (Identity Server 4).
First thing to note is that everything works if I run both client and server on localhost.
It is when I deploy the Identity Server to a Staging Server inside our network that things go awry.
So, the hostname of the Idp now differs to that of the SPA (which would be normal in production).
After much work, I've got everything working except IE11 (yep IE).
I had to do several things to get me there such as:
solve the samesite cookie issue of Chrome
create self-signed certificates and install the root certificate in the Trusted Certificates
add Babel config code and Core.js at the client, to enable IE to not throw errors when promises come into play
So, it's been a long road, yet still, I have to deal with this (see animation):
I just can't quite figure out why IE is doing that.
It is not possible to use the dev tools to see any info.
The logs at the server do not contain any information that seems relevant.
Has anyone else seen these "Browser symptoms" in IE.
Happy to provide more information (code, logs etc.) if people think that will help. Just didn't want to dump all that in the initial question, as many people don't like that.
Here are a couple of Fiddler screenshots. The first is from Chrome:
The second on is for IE11.
For some reason, the Silent Refresh is being invoked over and over again with IE11.
I think I can see what is happening, but not sure how to fix it.
There appears to be 2 calls to the Authorize endpoint which fail, conspicuously missing the .AspNetCore.Antiforgery cookie. This results in 2 invocations of silent-refresh.html.
Then, for some reason there is some king of GET request to the base url of the Idp and immediately following on the heels of that request is a request to the Authorize endpoint which does have the .AspNetCore.Antiforgery cookie.
The ship is set straight until the next call to the Authorize endpoint which is the beginning of the next cycle.
However, with Chrome, after the user is logged in, the next call to the Authorize endpoint does contain the cookie.
So, I guess it is the missing cookie which is the issue.
Perhaps this has something to do with the code which I used from this post to solve the Chrome samesite cookie issue?
Cheers
I am running a website on Google App Engine. From time to time I get out-of-control bots or perhaps brute force hacking attempts that I see in my logs. Recently I've had a bot (I presume) trying to access administrator/index.php several times a second. That file doesn't exist on my site. If I try to access it, I get the standard 404 and this in my logs:
But for the bot I am seeing HTTP 301 in the logs and I'm wondering why. Does Google interpret the requests as a denial of service or other attack and automatically intervene? I haven't seen documentation stating as much, but I'm not sure why else I would be seeing the 301 instead of 404 for the same URL:
Does anyone have an explanation for this?
The log entires shown on the screenshots can be clicked & expanded to view additional information. As mentioned in the comment above two things could be checked there for further analysis of what's going on:
check the hostname of where the request came to & see if it's not the expected behaviour for that hostname.
if the json object is shown, navigate to protoPayload -> line -> [0] -> logMessage where something like redirecting "http://example.com/" to "https://www.example.com/" should be shown which could also clear things up a bit.
(yes - cross-posted from the google-appengine google group...I can't tell if they answer support questions like this there or here or what...it's all kind of a mess :) )
I am having a problem logging in to the appengine console using certain accounts on my google apps domain (but not others).
No matter what browser I use (Firefox, Chrome, Safari, IE), I get a "too many redirects" error on https://appengine.google.com/start when I try to log in using a specific account. I have tried resetting all the browsers as well (clearing all cookies, cache, etc - even trying it on a clean install of an OS) - with no luck. Going directly to https://appengine.google.com/a/domain.name causes the same loop for those accounts. The same thing happens when running the browsers with privacy mode enabled.
One of the accounts having problems is the user nathan.toone on the k9webprotection.com google apps domain - however we can log in with the user "admin" or the user "build-agent" on the same domain just fine (but not "build.agent" or "user2"). It seems to be all over the place as to which accounts are able to log in without the redirect loop and which ones aren't.
I have contacted google apps for your domain support, and they have said that it is outside their scope. They very "helpfully" pointed me to https://developers.google.com/appengine/kb/general - which didn't help AT ALL. :(
Again - the odd thing is that there are some of the accounts on the same domain that are able to log in just fine. Does anyone have any idea what could be happening, or have a way for me to contact someone to get this worked out? I have found a couple of other people saying they have had this problem, but have not been able to encounter a solution.
-Nathan
I am getting an endless loop with a concrete5 site that just went live today... it was fine in development using a temporary URL, but now live only the homepage works... was wondering if this has something to do with pretty URLS.
error: Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.
Site is http://redletterdaysforbusiness.co.uk
It seemed all was okay with the rewrite rules, and the error was in fact within C5 itself...
When developing the test site I had enabled pretty URLS, once I went live and changed the URL this didn't work anymore.
By disabling pretty URLS, all links worked. Then re-enabling prety URLS, everything still working.
Thanks jcem for you input.
I have links which are pointing to a javascript method. The javascript method call some ajax logic and decides which file to download. If i add my site URL into trusted sites clicking on these links shows up a yellow bar as a warning which then allows me to download the file. Can anyone suggest how to avoid that yellow bar. Or whats the reason behind it.
You have to change it to a custom setting, even trusted sites disables automatic download. Look in the security settings under Download -> Automatic prompting for file downloads, and change it to Enable. Disable means you get the bar. Changing the security level to Low also does this.
It's a security mechanism to prevent unexpected drive-by downloads in sites, even trusted ones.