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.
Related
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?
I have an application that rotates an auth token cookie values regularly.
Each time the server rotates the token, it will not mark it as "good" until it sees the client has the token (cause the client includes it in the request headers for a resource).
I have a very specific situation ONLY on iOS (10.3) where sporadically it will send a very old cookie when network conditions change (eg: get off the subway). When this condition hits it "forgets" about the most recent cookie value and "starts living in the past" and sends and old value.
** Security note: IP addresses are publicly allocated t-mobile in NYC and token has long been deleted from our DB
Is this a known issue?
Are there any workarounds for cookie handling that is more robust on iOS? localstorage is not ideal cause these cookies are http only.
To clarify ... this is the flow:
Client (iOS Safari) has a cookie called _t with the value old
Client (iOS Safari) makes a request to the server
We issue Set-Cookie and set _t cookie to a new value new (http only, secure cookie)
Client makes another request with the new cookie value new. We flag that the cookie value is good and client has it.
Time passes
Client makes a request with the _t cookie with the value old
Here is my theory of what happened:
From the cookies lifecycle, whenever user authentication state change (login user -> logout user || logout user -> login user), the old cookie would be invalidated and replaced with a new cookie.
But why that happened in the subway and not other places?
1. These days most subways provide free unsecured WiFi to supplement the bad wireless network connectivity while underground.
2. There were some reports on network connectivity issue in 10.3, and
this one in particular is interesting, as the issue was location dependent.
3. I think the combination of (1) and (2) above was causing the app to reauthenticate to the server. Maybe you could pull the logs to check if that is indeed the case?
Possible workaround?
Maybe none. We can't prevent iPhone user from doing iOS upgrade. And most already did.
Also, the security repercussion of not changing cookies after reauthentication is worse.
Update based on the comment as of 05/31/2017:
Given the details as in the comment. We could have better explanation.
In cookie life cycle, when user logout, server-side-invalidation should take place.
The work flow:
1. When the user logout, the authenticated sessionID is deleted from the browser.
2. But that's not enough. The server needs to invalidate that sessionID too. Else there could be security repercussion.
3. It could be that in your case the server didn't invalidate. Thus it still expecting a SessionID which has been deleted from the browser.
This is just one possible explanation. To be exact, more details log file analysis and more experiment would be required.
For example, during that period, at the server log were there any reauthentication took place? Could we test in a controlled environment, if the server-side-invalidation has been implemented properly?
My experience
I also use authentication via IDs that change with each request and are stored in cookies.
I can confirm this behavior and it is still present in iOS 11 (and iOS 11.1 beta 3). In my log files, I can see that sometimes old cookies are randomly stored in Safari. This happens in a standalone webapp when it is closed and reopened.
My Fallback method
I built a fallback method over localStorage. A request with an old cookie will normally mark all data in my database as invalid. If the user agent points to a device with iOS, I do not mark the data as invalid and give the client a second attempt to authenticate itself.
On the client side I check the localStorage and create new cookies with this data. Subsequently, a new authentication takes place. The localStorage is rewritten like the cookies with each request. If authentication fails again, I mark the data as invalid.
Safari View Controller no longer shares cookies with Safari in iOS 11 and up, this change resolved the cookie store corruption issues that plagued iOS. We have not experienced this issue ever since iOS 11 was released.
Maybe that's caused by automatic retries?
Those posts mention that can happen under bad network conditions (like you said, subway):
https://medium.com/#fagnerbrack/the-day-a-bug-was-fixed-only-because-the-ceo-called-in-f653a34079eb
https://blogs.oracle.com/ravello/beware-http-requests-automatic-retries
SQLite database, if you're willing to sacrifice a little security.
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!
I tried to enable Jenkins CI security according to instructions in the wiki (the “Initial Steps” part). When I save the configuration, the browser asks me for some credentials, but since I haven't set any yet there is no way to get in to create a new user account (according the page above) and as a result I'm getting
Status Code: 401, Exception: Bad credentials
To get back into Jenkins, look at this page: Help! I Locked Myself Out.
To prevent what happened from happening again, I have always found it easiest to enable the security (I'm not sure which method you set), and then add my own user with the "Add" button.
I had the same problem using Chrome on Linux and getting locked out every time by
an auth popup as soon as I saved the security settings.
I found that using either a Chrome "Incognito Window" or Firefox worked Ok.
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