Using BlazeDS, I have developed a simple chat room but how do I go about showing who is online and what happen if the user close the web browser without disconnect, will the user name in the online list be remove immediately?
I use mx.messaging.channels.StreamingAMFChannel and set
<subscription-timeout-minutes>3</subscription-timeout-minutes>
There is no way for the server to detect that an user closed the browser, so you need to catch the onbeforeunload event if you want to be able to remove the user as soon as possible (and not relying on a timeout mechanism). In this event send a request to the server and then you can remove the user from the online user list.
There are a lot of example how to catch the event..one is here.
Related
Today, our B2B web application times out user sessions after 6 hours of inactivity. If a user's session times out, the user is redirected to the login page, and then redirected back to the original destination after login (via a "returnURL" querystring parameter sent to the login page).
This works great for regular HTTP GET requests. But what if a user is in the middle of a long data-entry operation and then goes home for the night? If the user tries to submit the form the next morning, their changes are lost.
Instead, I'd like to enable a similar workflow for forms like we currently have for GET requests: the user clicks "save", the user is forced to re-authenticate, and (if login succeeds) then the form would be submitted. Another alternative would be to force a re-login, but instead of submitting the form, simply drop the user on the original page so that the user could try again to save changes.
All the data we need to submit is on the client-- it's not like we're storing data in the session that would have been lost.
Is there an accepted pattern to handle this case? Should I use a window.open popup window and close it after successful login? Use a jquery dialog overlaid on the page? Something else?
I know that login UI is often treated specially by web apps to reduce cross-site scripting risk and for other security-related reasons, so wasn't sure if there was a well-known best practice for this use-case.
One way to handle this would be to periodically save drafts of the user's work, like StackOverflow does. For cost reasons that's not practical in our case-- for now we simply want to make saving-changes workflows resilient to session expiration.
We're using ASP.NET MVC on the back-end if it matters, and jQuery on the front end, but my question is really more about security and programming best practices that I'd expect to be platform-neutral.
It would depend on the amount of data being collected, but a possible solution could be to save the page state to the browser's local storage using either "localStorage" or "sessionStorage". "localStorage" and "sessionStorage" are properties of the web browser that are exposed in Javascript and are supported in most modern browsers (Chrome, Safari, Firefox, IE 9+). "localStorage" holds data indefinitely while "sessionStorage" holds data until the browser or current tab is closed.
It may be possible to store everything needed about the page, redirect the user to log in, and then reload the page using the stored data.
Before redirecting to login:
if (window.sessionStorage) {
window.sessionStorage.setItem("firstName", $("#firstNameField").text());
window.sessionStorage.setItem("lastName", $("#lastNameField").text());
}
After retunring from login:
if (window.sessionStorage) {
$("#firstName").text(sessionStorage.getItem("firstName"));
$("#lastName").text(sessionStorage.getItem("lastName"));
}
Original post:
This web application sends out emails which contain a link to a URL.
Correction-Clarification 9/17/2014:
An .EXE running as a scheduled task on a server (in "support" of the web app and connecting to same database) sends out emails which contain a link to a URL.
The nature of the email content is essentially a "reminder"; the link when clicked is essentially an acknowledgement signaling "done".
Resumption of original post follows:
Clicking the link in the email does 2 things at the target .ASPX page:
the page logic updates a database and sends another email to the same user
the page finishes by displaying a "success" message in the browser
Would it be bad design to eliminate the success message sent by the browser?
I'm thinking the opening of the web page just to announce "success" is not needed. If the target URL were replaced with something with no user interface (e.g. HTTPHandler, webservice) then I'm thinking the email sent back to the same user confirming "success" would be adequate.
Yet, part of that approach "feels awkward", I guess because normally clicking on links in emails causes web pages to open. Given these requirements, would this be bad design to eliminate the browser?
UPDATE - 10-17-2014:
see: Submit to HttpHandler results in RequestType GET instead of POST
update below
Actually, it's bad design to have a state change occur based on a GET request. A number of email systems (and virus scanning software) will follow the link in order to determine whether it should be quarantined or not.
Never mind that a GET request causing a change in state is pretty much against how the web is supposed to work anyway.
What should happen is they click the link, then the mail program opens the browser. You then show a page asking them to confirm the action by clicking a button. That buttons makes a POST request which you then act on.
Finally, I'm not entirely sure how you would eliminate the browser anyway. The mail program detects that it's a link and opens the browser once the user clicks on it. This is no different than how things like opening word documents or zip files. The email program just asks the OS what program is supposed to handle the action and passes it off to that program.
With your update, I think there's a much cleaner way. However this is dependent on the capabilities of the email client that'll be receiving the messages. Should be good for the vast majority of them.
In the body of the email, instead of sending a link, include an HTML form that contains a button which performs a postback to your server. See this ( link ) for samples of how some other companies have done it.
This way the action is a single step instead of two AND you aren't doing things the Wrong Way(tm).
I am developing a web site using ASP.Net 3.5 C#. I am listing all the Online users ( users who re logged in on my site) in my site. I want to track and update user's status in Database when a user has logged out or simply closed the browser or navigated to some other site. In all these cases I want to update user's status as "Logged Out".
How can i move forward with it.
Thanks
Vivek
When the user clicks the button, you can just handle the click event on the server-side (in code-behind) and then log the status change.
For the case where the browser is closed, you can handle the Session_End event in the global.asax, which fires when the session ends:
public void Session_End(object sender, EventArgs e)
{
// Fires when the session ends
}
Legitimate logout (i.e. Logout by clicking on logout button etc.) can be tracked easily. You just have to handle the event and mark their database status logged out.
However closing the browser is one thing I never had a good success with. You will get many solutions over web which would tell you to capture the close button and then ajax request etc, but I did not have success with any one with that.
(Things like Session_End may come handy but there is a Gotcha that thisevent does not get fired, if you are using anything other than IN-PROC session mode so that's not reliable).
You don't really know if the user has closed the browser or not, or if he navigated to another site. I think you need to use some sort of AJAX control that would send some messages to the server in a given time interval to make sure the user is viewing your site.
First check my answer in this other question:
session Handling in asp.net
You wouldn't be able to immediately close a session and track this change if some user closes the browser, shutdowns computer or something like that. This is achieved by playing with session timeout.
Another possibility could be consider an user online if it triggered some operation against the server in some time interval, thing that'll be implemented in your server logic.
Logging out should be easly trackable because it's an "human user" action. Just implement a "UserLogout" event in your authentication manager class or any other class handling authentication and track logouts there.
Client-side user actions like browsing to another page or closing Web browser can't be tracked because technology limitations: API lacks in this area. It's more because of Web paradigm and its principles. You'll need to miss that.
How woulld I set this up:
I wanna save what links a user clicks on in a website. I thought of creating a jquery function that would save the link name everytime a link is clicked , then ajax the info to the db after the user closes the site.
Does that sound like a proper way. Anyone have samples of that?
Since there are multiple pages with multpile links, I wanna create something equivalient to a Session variable in javascript so I can append info to it everytime a user clicks a link and send the info only once to the db, instead of everytime a user clicks a link open a db connection and send the info.
The links are products so I wanna save related products, so I wanna save related product infomation. Maybe I need a cookie instead?
Waiting till the user leaves the site is nice in theory but never in practice. Because you can't really know for sure when a user is leaving -- or it might be to late (eg a user shuts down the computer.) What you really want to do is keep track of the actions of the user as they happen using ajax.
To do this you need to assign every user session a unique id. ASP.NET does this for you (there is a session cookie created for every visitor to the site.) Using the ASP.NET session identifier will save you a lot of work.
Every time a user performs an action you want to save you just have jQuery make an ajax call (you don't care about the return) to a service that logs to your DB.
Here is the Microsoft docs about the automatic SessionID MS Doc
Or simply use the following code to get the unique id:
string sessID = System.Web.SessionState.SessionID;
Simpler way is just give user unique cookie. On server you always know on what page user come in. ($_SERVER in php) so your server side script could save it in database (with SID).
use localStorage for HTML5 browsers or cookies for older browsers.
$("a").click(function() {
car links = localStorage["links"];
links = JSON.parse(links);
links.push(this.href);
localStorage["links"] = JSON.stringify(links);
});
Then listen to the onbeforeunload event and make an ajax call to the browser sending it the localStorage["links"] JSON.
How do i keep checking if a user still is active, for like every 1 minute? I need to know which user is currently active and who is not! I'm not using ASP.NET membership provider!
Lets say, maximum 3 log in are allowed for one user to log in simultaneously from 3 different locations, if the same user, which is the 4th log in, try to log in from another location again, i would like to block the 4th log in.
I have few issues regarding this as well! If the user unplug the connection cable or close the browser, how do i figure out if the user is still active?
I would need more detail about exactly what you are trying to accomplish, as you have asked a fairly vague question. However, I would think the best way to determine if a user is active is to check if their ASP.NET session is still alive. There is no "accurate" way to test if a user is still browsing your site, because they could be sitting there reading, or be AFK, or be in another program on their computer...dozens, if not hundreds of scenarios could exist on the client side.
However, the user's ASP.NET session will only live for a specific period of time between each activity from the user (GET, POST, etc.) Usually after 20 minutes, ASP.NET will clean up the users session, and when it does, it will fire a Session_End event that can be handled either in Global.asax, or with a custom HttpModule. You would then be able to flag that user as inactive in your own database, send an email, or do whatever it is you need to do.
You can use the HttpResponse.IsClientConnected property to check if the user is still conncted to the session. For details see this -->
http://msdn.microsoft.com/en-us/library/system.web.httpresponse.isclientconnected.aspx
Alternatevely, you can set a counter at Session_OnState at global.asax to check for the active session available and do your stuff based on that.