I am developing an application that requires the user to select a client certificate to authenticate, and do so by overriding the OnSelectClientCertificate method of the browser's request handler.
On initial authentication this works fine, but I want to be able to allow the user to logoff while keeping the application open and reauthenticating with a different client certificate. the problem is that OnSelectClientCertificate never seems to be called again. Have tried deleting all cookies and calling CloseAllConnections but still no luck.
Does anyone know the solution to this?
did manage to find a solution to this problem, it is as amaitland said that the certificate selection was cached per RequestContext, so to get it to prompt again I moved away from using the global RequestContext and instead used a new RequestContext whenever I needed to prompt for a client certificate again.
Related
I've been using Postman in my app development for some time and never had any issues. I typically use it with Google Chrome while I debug my ASP.NET API code.
About a month or so ago, I started having problems where Postman doesn't seem to send the cookie my site issued.
Through Fiddler, I inspect the call I'm making to my API and see that Postman is NOT sending the cookie issued by my API app. It's sending other cookies but not the one it is supposed to send -- see below:
Under "Cookies", I do see the cookie I issue i.e. .AspNetCore.mysite_cookie -- see below:
Any idea why this might be happening?
P.S. I think this issue started after I made some changes to my code to name my cookie. My API app uses social authentication and I decided to name both cookies i.e. the one I receive from Facebook/Google/LinkedIn once the user is authenticated and the one I issue to authenticated users. I call the cookie I get from social sites social_auth_cookie and the one I issue is named mysite_cookie. I think this has something to do with this issue I'm having.
The cookie in question cannot legally be sent over an HTTP connection because its secure attribute is set.
For some reason, mysite_cookie has its secure attribute set differently from social_auth_cookie, either because you are setting it in code...
var cookie = new HttpCookie("mysite_cookie", cookieValue);
cookie.Secure = true;
...or because the service is configured to automatically set it, e.g. with something like this in web.config:
<httpCookies httpOnlyCookies="true" requireSSL="true"/>
The flag could also potentially set by a network device (e.g. an SSL offloading appliance) in a production environment. But that's not very likely in your dev environment.
I suggest you try to same code base but over an https connection. If you are working on code that affects authentication mechanisms, you really really ought to set up your development environment with SSL anyway, or else you are going to miss a lot of bugs, and you won't be able to perform any meaningful pen testing or app scanning for potential threats.
You don't need to worry about cookies if you have them on your browser.
You can use your browser cookies by installing Postman Interceptor extension (left side of "In Sync" button).
I have been running into this issue recently with ASP.NET core 2.0. ASP.NET Core 1.1 however seems to be working just fine and the cookies are getting set in Postman
From what you have describe it seems like Postman is not picking up the cookie you want, because it doesn't recognize the name of the cookie or it is still pointing to use the old cookie.
Things you can try:
Undo all the name change and see if it works( just to get to the root of issue)
Rename one cookie and see if it still works, then proceed with other.
I hope by debugging in this way it will take you to the root cause of the issue.
I am having a problem implementing Microsoft's latest Identity 2.0 in my ASP.net 4.5 Web Forms project. This is my scenario...
I have downloaded the latest Webforms.Samples code from https://aspnet.codeplex.com/SourceControl/latest and pretty much performed a straight port (for the purposes of testing) into my project.
In development, the code/implementation works correctly, when we move to our IIS 7.5 staging server, after a period of time (usually 3 or 4 hours, but varies) the test users experience the following problem...
When they login, the login process appears to run correctly and redirects them back to the specified return url, but the authorisation is not complete/recognised and they get immediately returned back to the login page.
I should say that the login page/process doesn't fail (no errors) and the underlying code return 'success' (as this is the only path that will invoke the redirect), but the actual mechanism appears to be passive. To prove this, I have created a test page that simply echoes the user's identity and even immediately after an apparently successful login, the user identity is anonymous.
The only way I have found of fixing the issue is to restart the web application and again it runs fun for a while.
Can anyone give me any pointers on where I can look to begin to debug this issue or what the cause might be?
Thanks.
ASP.NET_SessionId + OWIN Cookies do not send to browser This page seems to provide a workaround to the issue by creating a session on application start up.
Starting with this great analysis by #TomasDolezal, I had a look at both the Owin and the System.Web source.
The problem is that System.Web has its own master source of cookie information and that isn't the Set-Cookie header. Owin only knows about the Set-Cookie header. A workaround is to make sure that any cookies set by Owin are also set in the HttpContext.Current.Response.Cookies collection.
The workaround I created is now outdated: I've made a small middleware
(source, nuget) that does exactly that, which is intended to be placed immediately above the cookie middleware registration.
Use Microsoft's suggestion of a SystemWebCookieManager instead.
Is there a way to access referrer information from the server log in a ASP.NET web application?
I would like to know if a customer comes to my web app from a specific site and change the app's behavior accordingly. I could have the webmaster of the other site include a query string, but to my knowledge this wouldn't work because as soon as Tom, Dick or Harry posted the link somewhere else, the query string would be unreliable.
Is there a sure fire way for a web app to know where the user came from?
Why not just check the Request.UrlReferer property and change the behavior if the referer is not any page on your site?
This would be a lot simpler than referencing IIS logs.
You can access the referrer information through the HttpRequest.UrlReferer object.
However you should note:
This can null - so check for null before calling AbsoluteUri on it.
This can be changed fairly easily, so you can't rely on it completely
Why would you not just access the Request host header for the HTTP_REFERER instead of the log file? See here, but note that you are never guaranteed to recieve this information, nor is it reliable if you do.
Request.UrlReferrer.AbsoluteUri
gives you the same as the server logs will. Probably a combo of querystring variable and UrlReferrer will do the best job of ensuring that it came from the right source.
UrlReferrer is sent by the client, and it's not guaranteed to be there.
Are you using a shared environment? Normally they will supply this if you request the logs (normally an option in Plesk or similar). The log directory will probably be one or two folders up from the root http folder, so it may not be accessible using the IIS user.
On a dedicated server then you can obviously configure this manually.
I have a web app that is being hit by facebook. The login page retrieves the keys that I need and sets some session variables. When the server then redirects the user to the next page, the session information is lost. I’m running the IIS engine on vista ultimate at the moment, the app pools don’t matter because I’m using a state service and I’m still losing the session state. I’ve tried both the overloaded method of the response.redirect function and also adding a header to the page to force the redirect and none of this seems to work. Does anyone have any ideas of what I’m missing?
I’ve tried both of these:
Response.Headers.Add("refresh", "3;url=Dashboard.aspx")
And
Response.Redirect("Dashboard.aspx", False)
[EDIT]
So i just did a little experiment and well it turns out that when I hit the url directly from the facebook page I get the problem, but when i copy the url for the IFrame into a new browser window and try it it works fine.
[EDIT]
So I found an article on this and after addin gthe header the problem was solved (for now)
http://support.microsoft.com/kb/323752
Response.AddHeader("P3P: CP", "CAO PSA OUR")
when I hit the url directly from the facebook page I get the problem, but when i copy the url for the IFrame into a new browser window and try it it works fine.
If you're in an iframe, any cookies you set are “third-party cookies”. Third-party cookies may be subject to more stringent conditions than the normal “first-party” cookies you are setting when the user is directly on your site. This can be due to different browser default cookie handling or because the user has deliberately configured it like that. (And for good reason: many third-parties are unpleasant privacy-invading advertisers.)
In particular, in IE6+ with the default settings, you cannot set a third-party cookie unless you write a P3P policy promising that you will be a good boy and not flog your users' data to the nearest identify thief.
(In practice of course P3P is a dead loss, since there's nothing stopping the site owner from just lying. Another worthless complication that provides no actual security. Yay.)
I'd try running Fiddler and see if your session cookie is being sent properly with the response when interacting with your app via Facebook.
The session depends also on cookie support by the client. When you say the app "is being hit by facebook" are you sure that by what ever means they are "hitting" you they are supporting cookies?
Response.Redirect and refresh don't carry session. Server.Transfer() can but loses the ability to transfer to other servers/sites.
I implemented OpenID support for an ASP.Net 2.0 web application and everything seems to be working fine on my local machine.
I am using DotNetOpenId library. Before I redirect to the third party website I store the orginal OpenID in the session to use when the user is authenticated (standard practice I believe).
However I have a habit of not typing www when entering a URL into the address bar. When I was testing the login on the live server I was getting problems where the session was cleared. My return url was hard coded as www.mysite.com.
Is it possible that switching from mysite.com to www.mysite.com caused the session to switch?
Another issue is that www.mysite.com is not under the realm of mysite.com.
What is the standard solution to these problems. Should the website automatically redirect to www.mysite.com? I could just make my link to the log in page an absolute url with containing www? Or are these just hiding another problem?
Solve the realm problem that you mentioned is easy. Just set the realm to *.mysite.com instead of just mysite.com. If you're using one of the ASP.NET controls included in the library, you just set a property on the control to set the realm. If you're doing it programmatically, you set the property on the IAuthenticationRequest object before calling RedirectToProvider().
As far as the session/cookie problem goes with hopping between the www and non-www host name, you have two options:
Rather than storing the original identifier in the session, which is a bad idea anyway for a few reasons, use the IAuthenticationRequest.AddCallbackArguments(name, value) method to store the user's entered data and then use IAuthenticationResponse.GetCallbackArgument(name) to recall the data when the user has authenticated.
Forget it. There's a reason the dotnetopenid library doesn't automatically store this information for you. Directed identity is just one scenario: If the user types 'yahoo.com', you probably don't want to say to them 'Welcome, yahoo.com!' but rather 'Welcome, id.yahoo.com/andrewarnott'! The only way you're going to get the right behavior consistently is to use the IAuthenticationResponse.FriendlyIdentifierForDisplay property to decide what to display to the user as his logged in identifier. It gives more accurate information, and is easier than storing a value in the callback and getting it back. :)
I dunno how OpenID works, but LiveID gives you a token based on the combination of user and domain. I just would have forwarded www to mysite.com.
The cookies and sessions and everything else get lost between www.site.com and site.com. I don't have patience enough to thoroughly read all the specs, but http://www.w3.org/Protocols/rfc2109/rfc2109 states that
A is a FQDN string and has the form
NB, where N is a non-empty name
string, B has the form .B', and B' is
a FQDN string. (So, x.y.com
domain-matches .y.com but not y.com.)
Note that domain-match is not a
commutative operation: a.b.c.com
domain-matches .c.com, but not the
reverse.
I think that means yes, you do need to forward to www. I have always added domain correction code to my sites when cookies and sessions are being used.