H
Regarding this URL
http://www.codeproject.com/KB/aspnet/FlashUpload.aspx
User.Identity as System.Web.Security.FormsIdentity is always null, because the Identity is GenericIdentity, I assumed it will be as in the tutorial FormsIdentity, what is chances.
Thanks
Rather than Casting to FormsAuthentication, Simply get the cookie .ASPXAUTH (or the name specified in the web.config) and send it to flash and then let flash put it as a POST variable while uploading, then Read Request.Forms[POSTVariable] and create the FormsAuthenticationTickt as illustrated by the tutorial in the question.
This is the problem with Flash, and it has nothing to do with your server side code and here is why.
When Flash makes web service calls, http service calls to the same domain it came from, it regains cookies and in turn the each calls are made within your session (ASP.NET Session), but when you upload something flash does not send cookie (A bug reported to adobe with no response till date).
This is the reason FormsIdentity is null, because ASP.NET Server needs cookie in order to assign FormsIdentity to properly authenticated user request.
Thats why when you upload, you will never get the session, the work around this is, we pass a custom authentication hash in querystring that we can validate on the server side.
Related
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.
I post this question cause i've passed lot of time to find the solution and find nothing about this on SO.
I'm using a .NET WebAPI as back end and store the user informations in the session.
For any reasons the session is lost in Chrome.
I receive the Set Cookie with the session id on my first request but the session is not set in Chrome but is set in IE.
I've try to change the web.config several time and change the configuration of the server but nothing changed.
I'm using fetch API for call my services.
Fetch does not send cookies by default. If your cookies are not HTTP only, you have to set them manually in the headers collection.
The issue is on the fetch and not on the server side.
The strange thing is that it's work on IE. Apparently IE don't have the same policy for the fetch API.
You have to make sure to add the property credentials to include or same-origin to keep the session on your request.
Warning : Put credentials to include fire a security error in Chrome.
The same-origin value resolved my problem.
Example of request :
fetch(uri,{
method:'GET',
credentials:'same-origin'
})
.then()
.catch()
I've read a lot of articles and made some own tests and what I can see from my tests and source code (IsCookieTokenValid and GenerateCookieToken - you can see there hard coded IsSessionToken = true) that ASP.NET Anti Forgery Token is per session, not per request (or POST request and so on). So token stored in the cookie remain the same during user's session. But token on the form changes (it's new) with every request (page refresh).
I've check if form submit with old form tokens are still valid, and they are. So what's the point to generate every time new form token if old tokes still valid and token in the cookie remains the same during the user's session?
I don't see in the code any setting to change this behavior and make token "one-time". The only option or solution is to delete the cookie and that will force to generate the new one. Correct? Any other ideas?
I ended up modifying ASP.NET MVC library and added setting GenerateOnetimeToken to AntiForgeryConfig to be able generate new pair of tokens (cookie and form tokens) with every page request (AntiForgeryToken() helper call).
Here is ASP.NET MVC 5 branch for this change.
In pageload, if you do Response.Cookies.Add(..., immediately in the next line, you can access that cookie via Request.Cookies(...
I know that under the covers, the cookie is added to Request.Cookies by .net, but the original request never had that cookie.
If what I'm saying is correct, why is it this way? Shouldn't the cookie be available in the following request? Shouldn't the immediate access to Request.Cookies(... be null?
You're right, ASP.NET does do that behind the scenes:
After you add a cookie by using the
HttpResponse.Cookies collection, the
cookie is immediately available in the
HttpRequest.Cookies collection, even
if the response has not been sent to
the client.
-- HttpRequest.Cookies page on MSDN
Why is it like that? At a guess, it's because that's how developers expect it to work.
I am creating a myspace application and for some database entries I am using generic handlers which I have hosted on another website. From my myspace application I use ajax calls to those handlers to perform the activities that I want. I want to know how can I make these ajax calls secure? I mean I want to be sure that the handlers are being called by only the myspace app and not by entering url into the browser etc. Any ideas?
You can secure you Generic Web Handler by doing trick with UrlReferrer for e.g
if (context.Request.UrlReferrer == null)
{
context.Response.Write("Invalid Request");
return;
}
In addition you can check if UrlReferrer != null then domain Name must match with your incoming request url say for e.g.
if(Request.UrlReferrer.ToString().indexOf("http://www.tyamjoli.com")!=-1)
{
//Valid request
}
This is 100% impossible. Everyone will have access to your javascript and can modify it however they want. They can use TamperData to view all requests that the browser makes and drop/modify/replay them.
I don't know much about myspace apps but is there a server component to it? If so, you could first request a "token" from the app which would be the encrypted action and some arbitrary timeout, say 3 seconds. The token is then passed to the generic handler which decrypts it then checks the timeout. If valid, then the decrypted action is performed.
Outside factors such as network latency and un-synchronized clocks could keep some actions from being performed. This should hamper simple replay attacks but is still vulnerable to a scripted attack.