2

If a user had some activity in the application, is there any way to find out that a request came from the same PC when the user returns back to the application next time?
Another side of the question is to protect the application from bots.

Just in case the solution depends on AS, I'm specifically interested in this for the Web application deployed on Glassfish v3.x. My application was created with JSF2, but I do not think it matters.

jjd
  • 2,158
  • 2
  • 18
  • 31
  • Cookies? They're machine-specific. – DOK Apr 07 '12 at 17:59
  • @Jmort253, thank you for the tip. I'm wondering if it helps me to recognize requests from a bot as well? – jjd Apr 07 '12 at 19:54
  • Sorry, @DOK, I've not get used of the UI and take a look at the wrong place. Previous comment was addressed to you. – jjd Apr 07 '12 at 20:11

2 Answers2

2

You could write a cookie to the browser that contained a unique token and store it in the user profile in the database. When the user logs in again pass the unique token to the server and compare with the token stored in the users profile in the database.

I just did some reading and it appears getting the mac address is out of the question: how to get a client's MAC address from HttpServlet?

Community
  • 1
  • 1
Kevin Bowersox
  • 93,289
  • 19
  • 159
  • 189
  • ,I studied this as well and came to the same conclusion. Could you please tell me if it works for bots? What if cookies are prohibited on client's side? – jjd Apr 07 '12 at 20:03
1

NOTE: The only way to reliably identify a returning user is via authentication. Using cookies, you're really checking for returning connections from the same browser.

If the user clears cookies, re-installs the browser, uses another browser, or uses another computer, your web application most likely will not remember them. With that said, here is one way to identify returning users without authentication:

The HttpSession is one way to detect a returning user. When a user has activity on your Web application, you can store a key that uniquely identifies that user. This places a cookie in their browser so that when they return, your Web application can pull that data from the session.

From the HttpSession javadocs:

Provides a way to identify a user across more than one page request or visit to a Web site and to store information about that user.

Record user activity:

ArrayList activity = new ArrayList<String>();

activity = (ArrayList<String>) request.getSession().getAttribute("activity");

if(activity == null)
    activity = new ArrayList<String();

activity.add("Searched for parts for Ford Thunderbird");
request.getSession().setAttribute("activity", activity);

Display user activity:

ArrayList activity = new ArrayList<String>();
activity = (ArrayList<String>) request.getSession().getAttribute("activity");

if(activity == null) {
    log.info("No activity to display. New user");

} else {
    for(String a : activity) {
        log.info(a);
    }
}

Setting the timeout in web.xml:

<!-- Define the default session timeout for your application,
     in minutes.  From a servlet or JSP page, you can modify
     the timeout for a particular session dynamically by using
     HttpSession.getMaxInactiveInterval(). -->

<session-config>
  <session-timeout>30</session-timeout>    <!-- 30 minutes -->
</session-config>
jamesmortensen
  • 33,636
  • 11
  • 99
  • 120
  • aren't session cookies temporary cookies? If so there would be an issue if the use came back in a different browser session or a week later. I think they are trying to detect the user a decent amount of time later. I suggested a persistent cookie but there could still be a large amount of circumstances that would prevent either method. – Kevin Bowersox Apr 07 '12 at 18:40
  • The session timeout can be controlled in your web.xml file. You can also set this dynamically on the HttpSession object. See the javadocs for details. I also updated my answer with the first sentence from the javadocs on HttpSession: "Provides a way to identify a user across more than one page request or visit to a Web site and to store information about that user.". I think you're right that in most cases, sessions are generally used for authenticated users. This isn't a rule, just a general observation. I don't think you'd be wrong in using a session. – jamesmortensen Apr 07 '12 at 18:49
  • @kmb385 - Also, you're right that this won't detect a user if they clear cookies, use another browser, use another computer, etc. The only way to reliably identify a returning user is through a registration process where the user authenticates with a username/password, OAuth, openid, etc. – jamesmortensen Apr 07 '12 at 18:53
  • Thanks for the comments. I do not have intention to authorize a user. User is authenticated with a user/password pair. Actually the main goal is to prevent actions which does not make sence. For example, if a user wants to create 20 accounts each day, I need a way to prevent it. The question is even more interesting if the same is done by a bot. – jjd Apr 07 '12 at 20:24
  • @jjd - Consider capturing and storing the IP address of the client making the request: http://stackoverflow.com/q/718785/552792. This is more robust, when combined with sessions or cookies, as the client cannot remove this data from your system. – jamesmortensen Apr 07 '12 at 23:26
  • @jmort253, an IP address is good if a client's host has a static IP address. Othervice it is not possible to recognize if requests come from the same host or from different which are under a NAT server. Have I got it right that everything I have is cookies and an IP? – jjd Apr 08 '12 at 08:22
  • @jjd - That's why I was saying that it's more robust *when combined with sessions or cookies*. I think that the two together help offset each other. For instance, you could rely on cross-referencing cookies with IP addresses. You detect someone with a cookie, record the IP, if the IP changes while they still have the cookie, you've got them! If the cookie is deleted and they visit before the IP changes, you have a chance to set another cookie. It's not perfect, but I don't think there is any other way around this other than be Google and be everywhere ;) – jamesmortensen Apr 08 '12 at 08:31