About to ask one clarification on open token expiration. For ex PF server is running on US and I'm accessing the application from Asia. I have set max life time for open token is 6hrs. So the time, open token reached my browser it will be expired.
though I'm authenticated already by PF can continue to access application but again i'm sending same opentoken to PF server(US server) for authentication.
In this case how PF will react?
Thanks In Advance.
Not sure I understand the question but I believe that you are asking about how OTK deals with timezone differences? If so, timeout eval is handled by the PF Adapter and Agent...not the client browser (except for persistent cookies..they have a timestamp of their own the browser enforces). The Adapter and Agent convert the server time to UTC before evaluating any timestamps within the token so that as long as the SERVER time settings are correct, it doesn't matter where the client (browser) is located.
Related
I have setup ADFS v5 on Windows server 2019.
I am trying to sync users from AD and store them to my application database. During this synchronisation process I am getting following error :-
System.DirectoryServices.DirectoryServicesCOMException (0x8007202C): The server does not support the requested critical extension. at System.DirectoryServices.SearchResultCollection.ResultsEnumerator.MoveNext()
Also I am getting this time out period expired error sometimes
System.Runtime.InteropServices.COMException (0x800705B4): This operation returned because the timeout period expired. at System.DirectoryServices.SearchResultCollection.ResultsEnumerator.MoveNext()
In order to fix this in ADFS management I have setup Web SSO Lifetime value as 480minutes & for one of the relying party configured I have TokenLifeTime set to 480
Do I need to change TokenLifeTime for all the relying parties configured?
Still same time out error is coming. I am new to ADFS I am not sure which configuration is incorrect.
Could you please suggest what all configuration changes I need to tweak in order to fix this.
I have the following use scenario: User logs in to ASP.NET application; and at some point makes a connection to remote TCP/IP server. The server's response may come after significant delay (say, a few hours). Imagine that the user submits a batch job, and the job may be running for a long time. So, the user may close the browser, get some coffee and come back to see the results later.
However, if client closes the connection, the server will never return the results. So, keeping Socket info in Application object won't work - once user closes the browser, it goes away.
Is there any other way to persist this open socket while IIS is up? Also, if the second user logs in, I would prefer to use the same connection. Finally, I realize that the solution is brittle, and it may occasionally break. It's OK.
Remote server is 20-year old mainframe application; so no chance for changes there. And as long as the user doesn't log out - everything is working fine now. Everything is on the LAN, so there are no routing issues to complicate the situation.
The contents of the application dictionary are not lost when a user logs out. Your scheme will work (in a brittle way, but you say that's ok).
Note, that worker processes can exit for many reasons, so expect to be killed at arbitrary points in time.
you have several options for persisting session-state: MSDN - Session-State Modes
inproc mode: you disconnect, state is lost. if you use cookies, and
store info/data somewhere on the backend, then you can map the GUID
to the data, regardless of session. or use application-state.
stateserver: persisted across disconnects and application restarts,
but not across iis/pool/server restarts, unless you use another
server, or cookie/auth. can be problematic sometimes.
sqlserver: as the name implies, uses a specially formatted db/table structure to persist state data across all sorts of scenarios.
custom/off: allows you to build your own provider, or turns it off completely.
here's the cookie method, by far the simplest (you have to generate a GUID, then store it in the cookie and application state or a backend DB): MSDN - Maintaining Session State with Cookies
you can persist cookies on the user's client. then, on server
reboot/client disconnect/any other scenario just pull the GUID from
app/session state or from a backend DB, which will also store the data
for the reports/output.
also, as a caution: even though cookies can be used to auth a user to an account/db record via GUID, it is considered insecure for all other purposes except unindentifiable information, such as: view shopping cart, simple reports, status, etc...
oh, and the stuff on IIS session timeouts (20 mins by default): MSDN - Configure Session Time-out (IIS 7) and MSDN - Configure Idle Time-out Settings for an Application Pool (IIS 7)
completely forgot to add the links on: ASP.NET Application State Overview, ASP.NET Session State Overview, but storing large amounts of data on a busy server in application state is not recommended. oh yea, and MSDN - Caching Application Data
On my website, members can write articles to share info with others in their community. I get random reports that the submit fails, and it appears it is because of session timeout.
If I create a small ajax script to "ping" an action on my ASP.NET MVC controller every few minutes, would that reset the session timeout? Or is there a better way?
An ajax ping is what I do in my Java EE MVC web application to keep the session alive, and it works fine. I don't see why it should not work for a ASP.NET application as well.
I am not sure if there is a better way, though.
Yes, that will do the job.
Independently of the technologies, every time an http request reaches the http server, the session "last access time" is updated to the date the communication has been initiated by the client.
If you ping to the server with a delay less than the session timeout you will preserve the session for ever!
Note: you don't need to ping every minutes if your session time out is 30 minutes. It will overload the network for absolutely nothing. I would recommend the session to ping every 25 minutes for such configuration.
HIH
M.
Imagine this szenario: Web-Server and WebDAV-Server using same cookie-domain.
WebServer sets some authentication cookie.
When starting an WebDAV-Session via special-link on the Web-Server,
WIN7 Microsoft Mini-redirector can read the cookie
set by Web-Server fine and starts an WebDAV-Session
on WebDAV-server using this cookie.
But after the first DAV-call, the cookie seems to be read-only
to both DAV-Server and mini-redirector.
DAV-Server cannot update this cookie
DAV-Server cannot delete (expiry in the past) the cookie
Mini-redirector keeps sending the old values
(even, if Web-Server has updated its values in between)
Anybody got informations
where mini-redirector stores its cookies
how to avoid this behaviour?
Thanks, Karl
I had the similar problem. On the client you should know when the server is updating the cookie. When you know server may reset the cookie, call wnetcancelconnection2 and clear of the the existing webdav connection and call wnetaddconnection2 to create the connection again. But give some time between these two calls atleast a minute, i guess it takes a while to clean up the existing cache.
In my application when i knew the server is going down or my application exiting or going to ask for new session, i call the wnetcancelconnection2 and wnetaddconnection2. It worked for me. Hope this helps.
Does anyone know a standard way to keep alive the http session as long user has open the flex app in the browser?
I played around with the polling mechanism of blazeds. But it had no affect on the http session.
Why do you need the http session to stay alive?
We have authentication enabled in our flex-weborb-.net application. If the session is terminated, the next call to weborb will throw a security exception. In this case we just re-authenticate and do the server call again. A new session is created and the user can continue his work. Like this, no polling is needed. I guess it's the same with blazeds.
If the session must stay the same, then I would suggest to ping the server every couple of minutes depending on the session timeout value.
There is no standard way of doing this. We do a ping-pong with the server every n-seconds (check the AS3 Timer class), where n must be lower than the session timeout. It's best to keep your session timeout as low as possible to reduce memory consumption on the server, especially when you have a lot of concurrent users.
One option is to submit an AJAX keepalive request from javascript in the hosting HTML page.