I have a RESTful backend which per definition is stateless. However, I do require authentication. For this, I plan to use Basic HTTP authentication. Since that requires the username and password to be sent with every request, I want to store them clientside.
I was thinking of using the HTML5 session storage for this. The overal browser support is good enough for my application but there is one issue.
I need to catch the event when the session storage is cleared, for instance by closing the tab or clicking the logout button. Before actually clearing the session storage, I need to send the credentials to the RESTful server one last time so it can perform a clean-up operation for that user.
The issue is not so much with the logout button but more so with the tab or browser being closed...
How do I catch this event (with some Listener perhaps?), and delay it from happening until I've made a final REST call?
As far as browser and tab concern you can try following link.
https://developer.mozilla.org/en-US/docs/DOM/window.onbeforeunload
Related
I am using Apereo CAS 6.3.3 generated by CAS Overlay project.
The integration with the application and LDAP is working well, but there are two problems that I have noticed. These problems are random and happens only with 20% of the requests.
1.) If someone directly accesses the CAS log-in page with ?execution=anything , the page shows the following HTTP 500 error.
org.springframework.webflow.execution.repository.BadlyFormattedFlowExecutionKeyException: Badly formatted flow execution key 'anything', the expected format is '_'
Is there anyway the error can be disabled and instead the page is redirected to application log-in page instead.
2.) Is there anyway the too many redirects error can be disabled for the expired service tickets so that the end user is redirected to the login page instead of first seeing the error message on the browser?
Thanks.
Is there anyway the error can be disabled and instead the page is redirected to application log-in page instead.
Applications that integrate with an SSO solution such as CAS do/should not have their own log-in page. After all, that's why they use CAS.
That said, to handle this error, you'll need to modify the CAS login webflow, and have it properly catch this error using what Spring Webflow calls Global Exception Handlers. Only then you can decide how to respond and handle the scenario with bad flow execution states.
Is there anyway the too many redirects error can be disabled for the expired service tickets so that the end user is redirected to the login page instead of first seeing the error message on the browser?
Yes. There is.
You need to get the application to respond correctly to failed validation attempts. If it sees a validation failure due to an expired ticket, the application should honor the failure, and ask for a new non-expired service ticket.
You may also need to adjust the service ticket timeout; perhaps there is lag or delay such that the ticket is seen as expired by the time it reaches the application, and is sent back to CAS for validation.
The best way to stop an infinite redirect loop is to stop the entity that is causing or sending those, and correct the mistake rather than hiding it with an error message. That's just an aspirin, and while it helps, it does not treat the underlying problem.
to the login page instead of first seeing the error message on the browser?
There is no login page, or the browser to redirect to. The failure is the result of a back-channel validation call. There is no browser.
User open the index page presented with basic browser authentication, but he doesn't respond and provides username/password.
In this scenario, I want to kill that http request, is there any way of doing it. I remember we can set a timeout cookie but not sure.
Would window.stop(); work? There's a way to cancel an ajax request using <object>.abort(); but I don't think that will help you in your situation.
What is the ejabbered behavior for user who is un-expectedly disconnected from internet
vs
user who explicitly sent an 'unavailable' presence?
Would they both be considered offline (for both single user chat or MUC)?
I want a behavior where if a user is disconnected from internet, offline messages to be sent
If user sent a explicit unavailble presence, I dont want offline messages to be sent.
How can that be accomplished? I can write my hook. But I need to know in which situations, the hook will be called.
When the user gets offline, the default behaviour is the same, no matter which method is used (explicit session close or unvoluntary disconnect). This is per XMPP specification.
If you want to customise the behaviour, it will not be easy as there is no way to know the reason why a user if offline.
What I would do: I would use the last module and support an optional reason for disconnect and store it. When you disconnect unvoluntarily, I would modify code to store reason being something like "timeout". When you disconnect explicitely, I would store another flag. When you get an offline message, you can then check the reason from being offline coming from mod_last storage.
I have two websites http://www.example.com and https://www.example.com. I am using HTML5 session storage to store user preferences.
A user arrives at http://www.example.com and I load some default settings via ajax.
They browse to a page requiring login and are sent to https://www.example.com/login.html
After they are done logging in they are sent back to http://www.example.com where because they are now logged in I should fetch new settings from the server. The trouble is that http and https are different origins and can't share session storage.
Things I've tried that don't work:
Loading a page http://www.example.com/clearSession.html in an iframe that just runs sessionStorage.removeItem('key') to clear my data, but it seems that this has it's own browsing context so it doesn't work.
Things I've tried that work but I'm not wanting to use:
Using a cookie. This works great because http and https can share cookies but this means all my user settings get sent to the server with every resource request. This is usually about 4k but could be up to 1MB of data. No I can't host my resources on a different domain.
Don't cache the settings and just make the request every time to get the settings. I am doing this on older browsers as they don't support session storage but it slows down the page load and puts extra load on my database.
I can tell you how we have solved this problem, but it doesn't involve local sessionStorage. We use a server-side session to store the user's login data (username, ID, etc.) after they have been to our authentication server and back. Before they are authenticated you could still collect preference data from them by using AJAX to report these preferences back to a web service on the server that can store it in the server's session scope. This would break the RESTful model, however, because it would assume the use of server side sessions. That would depend on your server language and how you have your web services set up.
I think you will always bump into that origin problem because that is a restriction designed into local storage in general.
Switch everything to https, its a standard now.
Our Architecture is using a Push Engine to send data to the browser ,
Could anybody please tell me what is the use of Push Engine ??
( Why is it required , as the same thing can be achivied using a normal AJAX programming )\
Please guide me .
let's say your visiting a website, and the website is updated continuously. Your browser needs to keep updating the data that you're viewing, meaning that the browser needs to keep communicating with the server, and get the updates.
you can use ajax to make requests every few seconds, each time fetch more data from the server. Problem is - you need to make a lot of ajax calls, and you open a connection (a socket) for each, and eventually, it is a very slow process. if the interval between the requests is large, you will have a delay between the updates on the servers, and the updates in your browser.
to solve that, we can manipulate the HTTP calls - keep the request (the connection) open, and continuously send data. that way, when the server wants to send something to the client (browser), there's an open connection, and it doesn't need to way for the next ajax call by the browser.
HTTP servers have a timeout on the requests, so just before request times out, browser will close it and make a new one.
another (better) method is using XMPP protocal, which is used in chats like facebook's and msn.
AJAX is a pull method - it requires the client to connect to the server. If you have some information that you want to display live - for example a live score in a football game - the AJAX call has to be made at regular intervals - even when there is no data waiting on the server. A Push Engine is the reverse - the client and server maintain a connection and the server pushes data when there is data to be sent.