I am trying to get a token stored in a cookie using Webview2. The login server has a complex process with many redirects, with DevTools from Edge I am able to see when my token (idToken) is received:
The problem is that I am not able to see all the requests in the code and therefore the request with the token.
I have tried using:
CoreWebView2.NavigationCompleted
CoreWebView2.SourceChanged
CoreWebView2.FrameNavigationCompleted
CoreWebView2.WebResourceResponseReceived
But none of them show all the redirects and requests of the authentication process. Can someone explain me how to see all the requests the browser goes through?
Related
I have been stuck in a .AUTH cookie bug for a while now with a website that uses form authentication in ASP.NET to log in the user. The website uses form authentication and ask for authentication information from a server that is running remote. Our website is not working with the response from production server, but the response from the staging server works just fine. These servers should be the same.
I looked into the problem for a while and find that for some reason the form authentication process using the response from production authentication server will drop the .AUTH cookie when send a GET request to Microsoft-IIS/10.0. I attached the request header and the response for both production and staging server. If anyone could possibly suggest the potential problem it will be great.
This is the worked one:
request
response
This is the bugged one:
request
response
As you can tell the request are pretty much the same, but the response missed the .AUTH cookie.
Please let me know what could potentially cause the issue, I am pretty new to ASP.NET.
Could this be Cross-Origin Resource Sharing (CORS) issue?
If the domain specified on the cookie is not the same as the back end then it will not be shared.
You might also find this answer useful if this is the problem
I'm developing an app and it access a website with HTTPS.
Requesting manually via incognito window, works.
Requesting via app using HttpClient, it never received a response.
I confirmed, via Fiddle, that headers are exactly the same between manual and app request. Via browser, a return comes in 1 second. Via app, it just hangs until eventually times out with an HTTP error 504. It is the exact same URL and exact same HTTP headers, checked one by one.
It is not a deadlock issue because in this case Fiddle would at least show the request completed. However the request stays open until it errors with HTTP 504.
Is it possible that the problem lies in the SSL process? There I noticed differences (in Fiddle). Both are TLS/1.2 version 3.3. The one via browser has SessionID, while the one via app this SessionID is empty. It is also missing some other data like ALPN, etc.
This would be the only thing I can think of, because the request is exactly the same.
Any help is appreciated!
Thank you.
We have a OWIN Web Api 2 site that needs both OAuth2 security and also Windows Integrated Security.
The problem is that when access tokens are expired. Owin returns a 401 unauthorized response. This causes the browser to popup a login box.
That's because there are XXX-Authenticate headers with Negotiate and NTLM values. Also one with Bearer
But if we disable Windows Integrated Security in IIS, then it doesn't have those headers but only has XXX-Authenticate: Bearer and so it the browser does not popup a login window.
On the client side, we want to catch the error code when the token is expired and then refresh the access token. This actually works except for the browser's ugly popup box asking for id and password.
But we must have both mixed authentication types for this application.
The solution seems to be to send back a different http status code for expired tokens so that the browser won't pop up the login box and we can still catch that code in the client.
However, I'm not having any success figuring how to do this with OWIN.
I registered a middle wear method at the top of the stack to look at
and modify the response code but when the token is expired it seems
to return 200 from OWIN but somehow gets changed to 401 when sent
to the client.
How can I change the status code returned only for expired tokens?
SignalR is working great except on every other page load, I get:
The error in the start and abort are
Unrecognized user identity. The user identity cannot change during an active SignalR connection.
At this point, though, if I do a ctrl+f5, it works great.
I'm on IIS 7.5 which means it's not using web sockets, if that matters.
Is it possible that another request that completes after SignalR's /negotiate request but before the /start request is setting a cookie that is changing the user's IPrincipal?
SignalR's /negotiate request returns a "connectionToken" (among other things) which serves as an anti-CSRF token. Every subsequent SignalR request includes the connectionToken in the query string, and the server verifies that the same user that requested the connectionToken is making the new request. If the user not the same , SignalR will respond with a 403.
As Marcel N. pointed out, this could also be caused by a user's session expiring, because that would effectively cause the user to log out. I think it's pretty unlikely that the session would consistently expire between the /negotiate and /start request however.
I need to sign in to a site, I can do this via an url such as url.com/ssorequest?parameters=123. If this is typed in the address im signed in in and gets redirected to the portal.
Now Im supposed to do this through a http post request programmatically but I cant get it to work, I get redirected to a sign in form instead of the portal, ie I dont get signed in.
I used Fiddler to find out what the difference between the two methods was. I found that a couple of behind-the-scenes get-requests were different. The browsers get-requests sends cookie data to the server and fiddlers post-request does not.
When I use fiddler to repeat the browsers first call it doesnt send the cookie data either. So it only works when I do it via the browser window. Unless I use breakpoints in fiddler and tamper with the requests to include the cookie data.
Q: Why does it behave differently from the browser with both http post and when the request is done from Fiddler?
Q: Is there any way to tamper with the requests going out programmatically in my C# app without writing my own Fiddler application?
Most probably you have encountered an anti-forgery cookie. It works in a way to ensure that you are signing in using the page that was first requested and loaded in the browser and the cookie is valid for one request only and hence the fiddler will not be able to log in if you run the same request again.
Using C#, you first have to request the sign-in page and get the cookies provided with this page in a cookie container. Next time, when you post the page along with data, you have to make sure that the cookie is attached with the request.
Edit:
Step1: Browse any page on the site. This will initiate the session. It will also give you the session cookie.
Step2: Request the sign in page. send the cookie obtained in step one along with sign in page so that it can recognize the session. This step is critical. At this stage, there can be either of two things depending on the security system site is using. Either it will send a security cookie along with session cookie or it will add a hidden variable in the form along with a value which serves as security token. Make sure that you get this token/cookie.
Step2: Post the login information on the sign in page (or whatever page the form action leads to) along with the cookie/token obtained in step 1. If it is a token, include it in your post data along with login information or if a cookie, add it to request.