I am using Nancy.Authentication.Forms. The users are vociferously complaining that their sessions are timing out too quickly (less than 5 minutes). I've searched high and low but cannot find how to set the session timeout time to one hour. Any help is greatly appreciated.
Thanks,
Ross
I'm not 100% sure what could be causing it because of the little information provided. But I think your problem is probably due to the encryption/decryption of the cookie.
Cookie Encryption differs on application startup
By default, a new key is created every time you start the application, which would cause decryption of the cookie to fail, causing authentication to fail, and requiring you to re-authenticate to create a new cookie.
By setting your own keys, every after restart the decryption will always be the same. This is VERY important if you have a load balancer.
https://github.com/NancyFx/Nancy/wiki/Forms-Authentication#a-word-on-cryptography
Since I also did not find an answer, I would like to post my research result:
WithCookie accepts an expiration DateTime.
https://github.com/NancyFx/Nancy/blob/a9989a68db1c822d897932b2af5689284fe2ceb8/src/Nancy/ResponseExtensions.cs
public static Response WithCookie(this Response response, string name, string value, DateTime? expires);
In my case it would be:
return Response.AsRedirect(redirectUrl)
.WithCookie(SecurityExtensions.CookieName, newSession.Id.ToString(), DateTime.Now.AddHours(1));
For the session duration itself I didn't find anything yet.
Related
Is there a way to delete the value from session witch revel the go web framework?
I have a function for validate captcha for user input, and I set the value of captcha in session, and delete the captcha from session if there nothing to do for client after 1 minute. The code is like:
time.AfterFunc(time.Minute, func() {
delete(this.Session, CSecurityCode)
})
But I can still get the old value of captcha , why, and how to fix this?
Anybody who can help me?
The Session value is valid only while processing a client request. i.e. between the time you get the request and the time you respond to that request. Its contents are kept in a cookie on the client side and you'll get a new Session every time the client connects to your server. Thus if you keep it for later use (like the name of your AfterFunc suggests, triggered by a timer?), anything you do with it will be lost on the next client connection.
In order to achieve what you want to do, you'll need to add a "lastSeen" timestamp to the Session. When a request comes in, check Session["lastSeen"], and if it's older than 1 minute, then you can discard CSecurityCode from it.
We're writing a custom SessionSecurityTokenCache so that our FedAuth cookies are valid across a webfarm with IsReferenceMode = true. We are also trying to enable sliding sessions, but it opens up a few questions around token expiration:
In Global.asax, we are handling the SessionAuthenticationModule_SessionSecurityTokenReceived event to check the remaining time on the token and reissue it if it is due to expire (within 5 mins, for example). In here, when we check token.ValidTo, it does not equal the expiryTime of the TokenCacheItem that we retrieved from cache. Why? How is TokenCacheItem.Expires supposed to be used?
In the AddOrUpdate method you're required to override, there's an expiryTime parameter; what is the intended use of this? Also asked here.
I have a question involving a "timeout" when sending an HTTPS "GET" request using the ServerXMLHTTP object.
In order to fool the object to send the request with the logged in user's id and password, I set it up to use a dummy proxy and then excluded the domain of the URL (on the intranet). So variable url_to_get contains .mydomain.com, while the proxy address is actually "not.used.com".
// JScript source code
HTTP_RequestObject = new ActiveXObject("Msxml2.ServerXMLHTTP.6.0");
// Using logged in username authentication
HTTP_RequestObject.open("GET", url_to_get, false);
HTTP_RequestObject.setProxy(2, "not.used.com", "*.mydomain.com");
try
{
HTTP_RequestObject.send();
}
catch (e)
{
}
In the catch block, I log an exception of "(0x80072EE2) The operation timed out". This is timestamped 1 to 2 seconds after a log message right before the open.
A retry will work as expected, and it can do it over and over again. Is this something on the server side? Or is it a result of the proxy?
Well this was painful and embarassing. I figured out the root cause of the issue I was seeing with the timeout. I had set the timeouts to "defaults" that were 3 orders of magnitude smaller than the real defaults. So even when I increased them to what I thought were really large values, I was still shorter than the defaults.
I had skimmed through the wording on the Microsoft page describing the setTimouts() method and misinterpreted the timebase of the parameters. I assumed seconds while it was actually milliseconds.
During the process of debugging this issue, I duplicated the code using the alternative COM object, "WinHttp.WinHttpRequest.5.1", and in verifying the equivalent API, SetTimeouts(), discovered the faux pas.
I did learn a few things in the process, so all is not lost, "WinHttp.WinHttpRequest.5.1" has a SetAutoLogonPolicy() [3] method that allows me to skip the hokey "proxy" foolishness required with "Msxml2.ServerXMLHTTP.6.0" to force it to send the user's credentials to an intranet server. I also fiddled with Fiddler [4] and learned enough to be dangerous!
Hopefully someone else can learn from my mistake and find this useful in debugging their own issue in the future.
Here are some inline links since I don't have enough rep to post more than two:
[3] : msdn.microsoft.com/en-us/library/windows/desktop/aa384050%28v=vs.85%29.aspx
[4] : fiddler2.com
Msxml2.ServerXMLHTTP.6.0 can be used via a proxy. It took me a while but persistence paid off. I moved from WinHttp.WinHttpRequest.5.1 to Msxml2.ServerXMLHTTP.6.0 at the advice of Microsoft.
Where varHTTP is your object reference to Msxml2.ServerXMLHTTP.6.0 you can use
varHTTP.setproxy 2, ProxyServerName, "BypassList"
Hope this helps and you pursue onwards with Msxml2.ServerXMLHTTP.6.0.
I am currently using openRasta to build Rest Api.I am observing strange behavior while sending Ajax requests.Sometimes request is successful sometime it fails and it gives following exception.
{Exception:
System.Runtime.Serialization.SerializationException: Expecting element 'root' from namespace ''.. Encountered 'None' with name '', namespace ''.
at System.Runtime.Serialization.Json.DataContractJsonSerializer.InternalReadObject(XmlReaderDelegator xmlReader, Boolean verifyObjectName)
at System.Runtime.Serialization.XmlObjectSerializer.InternalReadObject(XmlReaderDelegator reader, Boolean verifyObjectName, DataContractResolver dataContractResolver)
at System.Runtime.Serialization.XmlObjectSerializer.ReadObjectHandleExceptions(XmlReaderDelegator reader, Boolean verifyObjectName, DataContractResolver dataContractResolver)
at System.Runtime.Serialization.Json.DataContractJsonSerializer.ReadObject(XmlDictionaryReader reader)
at System.Runtime.Serialization.Json.DataContractJsonSerializer.ReadObject(Stream stream)
at OpenRasta.Codecs.JsonDataContractCodec.ReadFrom(IHttpEntity request, IType destinationType, String paramName)
at OpenRasta.OperationModel.Hydrators.RequestEntityReaderHydrator.TryReadPayloadAsObject(IHttpEntity requestEntity, IMediaTypeReader reader, IOperation operation)}
One thing i have observed is that when i keep browser idle for some time say more than 10 minutes i can see the request in firebug but it shows status as pending for long time and when it hits server it gives above exception.But same works fine sometimes.
Can anybody explain me this behavior?If want i can provide some additional code related to it.
The delay may just be caused by asp.net having to restart when you finally get out of idle, which takes a little while.
As for the error, it seems to be that the json data contract serializer can't parse the request. I'd advise to check a couple of things, and if it fails post here the details so we can help you further.
That the body is indeed correct at the time the error is triggererd (with fiddler)
That you do not have some asp.net-specific issues that would prevent the request from arriving correctly to the asp.net pipeline, such as cookies-based authentication or session management
That the request is not intercepted by any http module (anti forgery tokens etc).
Please provide your mappings, entities and a copy of the OR log (which you can get by attaching a debugger to the server process) and we'll try and help you further.
I am using code for session timeout (code comes from this link). This code generally works fine, except if user has waited long enough to hit IIS Idletime out (by default 20 minutes). Once Idletimeout is reached, because that w3wp process does not exists, it seem like this Redirect call to Home/Login goes into a long loop with 302s. Any idea how this situation can be better handled
Ensure this filter is not applied to your login action
The redirect will cause another request, so if the request is for the login page you have to let it through without doing another redirect.
Pseudo code:
if (current_request_url =! "~/Home/Login") {
ctx.Response.Redirect ( "~/Home/Login" );
}