I can't login to Stackdriver from the Google Cloud Console because of a login page redirect loop.
Here is the complete http request flow:
I can't provide you here the http request flow as stackoverflow said it looks like spam.
https://pastebin.com/im24CCnn
Request 3 and 9 are the login page of Stackdriver if presents me with ony the stackdriver logo and a single link with the text Log in with Google.
I've tried to restart the browser (Firefox) and clearing all caches and site data, with no change in behavior.
After some investigation, I figured out various causes for this case:
-1-
According to the documentation,
Stackdriver Monitoring relies on cookies from various Google sites to
manage Workspaces. If these cookies are blocked, you may find that you
get stuck in an endless authentication loop. Cookies can be blocked
accidentally, or by automatic updates pushed out as part of changes in
security policy at your location.
Solution:
-You must have third-party cookies enabled for the following:
google.com
accounts.google.com
apis.google.com
-Thus, after having cleared and enabled your browser cookies, make sure that they are not blocked, as for example by any extension like PrivacyBadger.
-2-
If you are logged into the browser with more than 1 account, it may cause a redirection behavior.
Solution:
-Try logging in from “Incognito mode”, or even a different browser to configure if the issue persists.
-Disable all your extensions and try again.
-3-
An update from the browser might interfere with the logging process in your browser.
Solution(same as the 2nd):
-Try logging in from “Incognito mode”, or even a different browser to configure if the issue persists.
-4-
If the version of the installed Stackdriver build is on Beta, then you might get this issue.
Solution:
-Uninstall Beta version and install a non-beta version of Stackdriver.
-5-
If nothing of the above works, please change your network and/or device and try again.
Additionally, during my research I came across few Feature Requests regarding the “Stackdriver Redirection Loop Issue”.
1-Allow the use of Google Cloud products without having cross-site tracking enabled.
2-Login loop attempting to access Stackdriver by using default settings of Firefox.
As soon as we can determine the cause, you can “star” the corresponding(one or more) Feature Request, so that it gets more visibility and also you may attach your email on the CC field, in order to get notified on any updates of the FR.
Clarification questions:
Were you able to login successfully to Stackdriver Monitoring before this issue occurred?
Related
I am trying build up a Staging Environment for an ASP.NET MVC Web App, but am stumbling from problem to problem, the last one having been this one: HTTP 500.79 Error / System.UriFormatException when deploying ASP.NET App to Azure Web App
Currently I am getting a HTTP 403 - Forbidden, "You do not have permission to view this directory or page." error when trying to access the page.
Authentication-wise the App uses Azure Active Directory as Authentication Provider, which is working fine in local testing (using a Test-AAD) and in production. The local and productive apps are not using Azure Web Apps. I noticed on the Azure App Service page that there is a possibility to specify authentication right within Azure, but I don't really want / need to use that, as everything is specified within the app resp. configured in the web.config (ClientID, ClientSecret and Tenant). Anyway, when I tried filling in the Authentication on Azure directly it did not work either, so I removed it again.
What happens now is that the redirect to the Login page on login.microsoftonline.com works, and according to the AAD Admin the login attempt is being successful, or at least shows no pecularities. However, when being redirected back to my page, I get a generic 403, without any additional information that could help pin the problem down.
I did check all sorts of logs for further details, and the only pecularity I found is that for some very odd reason, all requests are made to a completely gibberish URL:
Requested URL / specified Reply URL: https:\\skillmanagementtest.azurewebsites.net
Actually requested URL according to logs: https:\\Skillmanagementtest:80
I have absolutely no clue where this URL originates from, however, "Skillmanagementtest" with that capitalization seems to be the name I specified for the Azure Web App:
Screenshot resource group items
The web.config is being transformed properly during the CI/CD pipeline and I double-checked the auth settings there (tenant, clientID, clientSecret), and I am really out of ideas what may be causing this problem.
One hint I found on other problems was to check the IIS logs, but when I attempted accessing the directory these logs were said to be placed in I was rejected access, even though I have owner permissions on the App Service...
UPDATE
After a long and weary process of trying stuff out and discussing we finally got the App up and running. Some observations we made which may be interesting for others with this or similar problems:
The role-based authorization did not work because we forgot to specify the App Roles in the App registration's manifest file, and then link the security groups to the application roles. Check here for more info: https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps
We had one API which is only visible within our company's domain. As an Azure Web App runs outside that domain, trying to access that API resulted in an internal server error. We still have to find a solution for this.
We had a situation where requests to the reply URL after authorization would be redirected from HTTPS to HTTP. We have solved this, but as five people were trying out stuff consecutively we don't know currently what the fix actually was. We may create another Azure Web App which may then reveal this part of the solution.
Check to ensure that what you have in your web.config and app settings matches what you have in the reply URLs for your app registration in the portal. There may be some reference somewhere where the reply URL does not match.
Are you using the openid sample? https://github.com/Azure-Samples/active-directory-dotnet-webapp-openidconnect
Also ensure that you are logging in with a user who has the right permissions under the tenant and to the app itself. My colleague and I made a short video that includes the right configurations that may be helpful for this use case. https://www.youtube.com/watch?v=MohaxN6fsDs
After a long and weary process of trying stuff out and discussing we finally got the App up and running. Some observations we made which may be interesting for others with this or similar problems:
The role-based authorization did not work because we forgot to specify the App Roles in the App registration's manifest file, and then link the security groups to the application roles. Check here for more info: https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps
We had one API which is only visible within our company's domain. As an Azure Web App runs outside that domain, trying to access that API resulted in an internal server error. We still have to find a solution for this.
We had a situation where requests to the reply URL after authorization would be redirected from HTTPS to HTTP. We have solved this, but as five people were trying out stuff consecutively we don't know currently what the fix actually was. We may create another Azure Web App which may then reveal this part of the solution.
I am getting the following error when a request is send to the server. What does this message mean and how could I solve this.
p.a.m.DefaultUrlEncodedCookieDataCodec - Cookie failed message authentication check
I am trying to integrate Silhouette in my application. I am using cookie based authentication. I suppose the warning is related to it but I am not sure what it means and how to solve it.
You have to clear out the PLAY_SESSION cookie from the previous version of Play framework you were running. If you are using Chrome, go to Settings. Scroll down and click on Show Advanced Settings. Privacy -> Content Settings -> All cookies and site data. Here you have an option of clearing out all cookies or filtering by host (likely localhost if you are on your development machine) and deleting only the PLAY_SESSION cookie.
If done correctly, this warning will immediately stop showing up when you make a request to your server.
I am unable to open Google, Youtube, some other website in my browser. Its showing a Certificate authentication error.
I changed it as a trusted website. Now it showing like:
(Index of /[ICO] Name Last modified Size Description)
I have no idea what to do. I am unable to google.
Other websites like facebook, yahoo and Gmail load correctly in the browser.
This is the message in google-chrome:
Your connection is not private
Attackers might be trying to steal your information from
www.google.co.in (for example, passwords, messages, or
credit cards). NET::ERR_CERT_AUTHORITY_INVALID
The Message I am getting in chrome when I click advanced:
Hide Copy Code
www.google.co.in normally uses encryption to protect your
information. When Chrome tried to connect to www.google.co.in
this time, the website sent back unusual and incorrect
credentials. Either an attacker is trying to pretend
to be www.google.co.in, or a Wi-Fi sign-in screen has
interrupted the connection. Your information is still secure
because Chrome stopped the connection before any data was
exchanged.
You cannot visit www.google.co.in right now because the
website uses HSTS. Network errors and attacks are
usually temporary, so this page will probably work later.
Is this a problem with google servers, something in between or the client side browser? Is there a workaround for this error?
This is a Chrome issues. Switch to a different browser and you will be fine. Google has decided to make getting to sites without the "expected" SSL certificate almost impossible (you can go clear the cached cert info on a site-by-site basis, which is a real pain...but expect the problem to come back again and then you have to go clear the cached cert again).
If you are using web filtering or various real security products that decrypt / inspect / then re-encrypt traffic, Chrome dumps all over it.
I used to be a Chrome fan, but because of this issue I had to abandon Chrome. I'm not going to turn off my real security products just so I can keep using Chrome!
My organization had a web app that worked perfectly in iOS 6. You'd visit the website, the website would tell you to add the page to your homescreen, and boom, a nice HTML5 web app was added to the home screen.
Because we're processing sensitive data, the web app used HTTP authentication (via the native WebKit auth dialog) to authenticate user/passes. It worked without a hitch until iOS 7. Now when someone tries to summon the HTTP auth dialog, nothing happens. It's clearly trying to load something, as the spinner in the status bar appears, but no dialog ever pops up, essentially breaking the "app."
Has anyone else run into this? Is this something you'd consider to be a bug on Apple's end? Any workaround?
My company ran into this last fall, starting with iOS 6, and what we have been able to ascertain is that it is a genuine Apple Safari bug as part of its security "enhancements". No real explanation from them for rationale, but here is what we see in the debug and packet sniffers.
In normal operation, the Safari browser will request a page (or an object in the page) from the server on a GET. If that asset is protected with an Access Control List, in our case Apache Basic Auth, and it is the first request on that host in the session, the server will respond with a 401 HTTP response header indicating to the client (the browser) that it needs to request again, this time adding a basic auth header that has authorization credentials. The browser then presents a login dialog to the user, where they can enter user and pass credentials, and either submit or cancel the request. On submit, the client re-requests with those credentials in the auth header.
Assuming the credentials are accepted on the second GET request, the proper asset will be returned on the response, and the document in the browser will proceed with loading the rest of the page (assuming it was a page you requested). If you have embedded assets that reside on a different host, and that host requires authentication for that asset, the process is repeated as the page loads.
Here's where it gets broken. If you embed calls to objects from more than 2 hosts total on the same page, which require basic authentication, the 3rd authentication prompt on that page is suppressed, so the browser spins forever waiting for you to enter credentials on a prompt that you never see. Your Safari browser is now hung up on that stalled authentication prompt, on this and any other tab, even on a reload, and you will not get another prompt unless and until you hard-close your browser or restart your device.
This does not affect Chrome, just Safari, and it is both on an iPhone and an iPad with iOS 6 or later. I have the latest iOS version as of this writing (7.0.6), and the problem is still there.
We had a workaround last year, where we would create an internal page that had an array of each of the embedded hosts, which we would then loop through with an iframe embedding a call to the favicon.ico at that host's location. That worked until recently, where now, perhaps because of the iOS 7 feature of freezing background tabs, the auth prompts are frozen up again.
Here was the JavaScript sample:
hosts=["store","profile","www","secure-store","images","m","modules"];
devhost=location.hostname;
var i=0;
while (hosts[i])
{
newhost=devhost.replace('store.mydomain',hosts[i]+'.mydomain');
document.write("<iframe Xhidden seamless=seamless width=0 height=0 src=http://"+newhost+"/favicon.ico><img height='16' width='20' alt='NOT' title='NOT AUTHENTICATED' src=http://"+newhost+"/favicon.ico> Authenticated on "+newhost+"</a></br></iframe>");
document.write("<img height='16' width='20' alt='NOT' title='NOT AUTHENTICATED' src="+(newhost.indexOf('secure')>0?'https://':'http://')+newhost+"/favicon.ico> Authenticated on "+newhost+"</a></br>");
i++;
}
The second set in the document.write would give a visual indication of which hosts have been authenticated, as their favicon is now displayed. It also lets you know which host might be stalled, as its icon is missing.
Since this workaround stopped working on iOS 7, the only cumbersome solution we have is to pre-open a separate tab for each of the favicons (directly in the URL), enter the auth, go back, go to the next one in the list, and repeat until you have cached all of the auth credentials for all of the hosts used on the page. At that point, you can load the original page since your creds are now cached. Cruddy, and completely unreasonable for an end consumer, but is what we need to do for testing sites that are behind a public CDN, as we need to protect assets on that development site with an ACL.
As of today, we are still figuring out a better workaround. Not an issue on Android, Windows, or any other iOS.
Sure worked better when Jobs was alive.
Hope some of this helps.
I have the exact same problem. Basic authentication worked with previous iOS versions but not with iOS 7 in combination with web apps added to the home screen. I think this may be related to the dialog problem described here.
Standard dialogs are not working at all, such as alert, confirm or prompt.
The login prompt that is shown to authenticate the user is probably blocked (does not work or is not visible) and that is why the web app does not pass through the authentication phase.
I suppose Apple will have to fix this bug in a future release.
Edit: After upgrading to iOS 7.0.3 basic authentication suddenly started to work again also in home screen web app mode. Login prompt is displayed and everything works as expected.
I switched to the iPhone user agent during which time I visited Google, then I changed back to the default Firefox one again. I cleared all of my history, cache and cookies but Google still thinks I am on a mobile device and insists on directing me to the mobile site. I have checked my user agent and it is definitely the correct one and I have removed every single cookie in Firefox.
How is Google remembering this information? Is there some other sort of mechanism apart from cookies that remembers user settings? It doesn't do it in any other browser.
I've seen some issues such as this on Firefox. Which add-on are you using to change the UA?
To be absolutely sure what the UA String you can Check you User Agent String
Also you can check for cookies using the Fire Cookie Add-On
Normally i can fix this issue by Closing the web browser and starting up a new instance of Firefox.
My other issue with Firefox is that it caches HTTP redirection rules from a website, so if i change a HTTP redirection rule on the server Firefox does not immediately pick this up - This problem is also fixed by closing the web browser.
I solved this problem in firefox by resetting my default agent:
Tools->Default User Agent->Default User Agent
and then going to:
Tools->Clear Recent History->Cache