session mixup

[Joel Sander]

My server has a rare session mix that sounds something like this one:

https://coderanch.com/t/451902/JSP/java/session-mix

except that I observe it on rare occasion regardless of the number of users.

From looking through my code, the only type of request.set is the following:

request.setCharacterEncoding("UTF-8");

I do store a user token on login and just about every page retrieves it to get user data and as to use to make calls on the underlying servers:

<%
   UserToken userToken = null;
   if ( session.isNew() || ((userToken = (UserToken)session.getValue("uToken")) == null) ) {
%>
      <%@ include file="Timeout.jsp" %>
      //response.sendRedirect("logout.jsp");
<%
  } else {
      // Do the webpage stuff here
  }
%>

Any suggestions would be appreciated.

[William Brogden]

Looks like the userToken variable is shared by all requests executing that JSP. Why are you surprised?

Possibly because looking at a JSP does not really give you an idea of the resulting actual servlet code - look at the .java file being created by your JSP for illumination.

Bill

[Joel Sander]

William Brogden wrote:Looks like the userToken variable is shared by all requests executing that JSP. Why are you surprised?

Possibly because looking at a JSP does not really give you an idea of the resulting actual servlet code - look at the .java file being created by your JSP for illumination.

Bill

Hi Bill,

Sorry, I don't understand what you wrote at all.

Each session should have it's own userToken. I can't imagine the userToken doing anything wrong here itself. Unless Tomcat starts using the userToken stored in person A's session for person B, then I don't see how this can happen.

[Bear Bibeault]

Here's a few questions:

Why are you bothering to test whether the session is new or not? Either the session contains the token, or it doesn't. Why the extraneous check?

If all you are doing is checking for null, why the cast? It's unnnecessary. (And unnecessary code should be avoided.)

Why isn't this in a filter rather than being cut/pasted into every page? (Or a prelude at miniumum?)

Why are you using obsolete Java scriptlets in a JSP? Is this 12-year-old legacy code? If not, then you're using obsolete practices and technology from over a dozen years ago.

[Joel Sander]

Bear Bibeault wrote:Here's a few questions:

Why are you bothering to test whether the session is new or not? Either the session contains the token, or it doesn't. Why the extraneous check?

Why isn't this in a filter rather than being cut/pasted into every page? (Or a prelude at miniumum?)

Why are you using obsolete Java scriptlets in a JSP? Is this 12-year-old legacy code? If not, then you're using obsolete practices and technology from over a dozen years ago.

Thanks for the fast reply! That is one of the great things about this site!

* I don't remember why; I'm working with a system that was originally written several years ago. Seems like a reasonable "make sure nothing strange is happening" check.

* This is going to be a dumb question, but what is a "filter"?

* The code is primarily in server pages serving out text to javascript/html5 front pages. My understanding is that using JSP this way isn't a 12-year-old legacy style. If that is incorrect, it likely doesn't make sense to rewrite hundreds of pages to upgrade and why does Apache still make new versions of Tomcat?

[Bear Bibeault]

Joel Sander wrote:* I don't remember why; I'm working with a system that was originally written several years ago. Seems like a reasonable "make sure nothing strange is happening" check.

No, it isn't. It's unneeded and extraneous. Extra code is not only potentially harmful (as a bug magnet), it obfuscates the code and hinders clarity.

* This is going to be a dumb question, but what is a "filter"?

Servlet filters are code that run before and after requests. They're perfect for doing things that need to happen outside the main-line purpose of the request -- such as authentication checking.

Any time that you find yourself cutting and pasting the same code into multiple pages or controllers, it's a red flag that it should be factored out into a prelude, coda or filter.

The code is primarily in server pages serving out text to javascript/html5 front pages.

Ugh. That's a practice that has been obsoleted and denigrated for over 12 years now. Please read this article for an overview of modern web app structuring.

My understanding is that using JSP this way isn't a 12-year-old legacy style. If that is incorrect

It is very very incorrect. Sorry, but putting Java code into JSP has been frowned upon since the introduction of the JSTL and EL in 2001.

it likely doesn't make sense to rewrite hundreds of pages to upgrade

No, it doesn't. Which is why I asked if it is legacy code. There is no excuse for writing new pages in that fashion; but it also doesn't make sense to upset the apple cart on existing legacy apps without good reason for such a refactor.

and why does Apache still make new versions of Tomcat?

Ummm, in order to stay up-to-date with the latest specs. Odd question.

[Joel Sander]

Interesting and informative. I'll look into filters. Thanks! Are you saying that using Java to create server content is completely antiquated? Does that mean that all modern servers use php?

---

While interesting, I'm still facing the issue that Tomcat does sometimes swap the authentication tokens between sessions and no information or ideas about how to go about debugging this.

[Bear Bibeault]

Joel Sander wrote:Interesting and informative. I'll look into filters. Thanks! Are you saying that using Java to create server content is completely antiquated? Does that mean that all modern servers use php?

No. I said using Java in a JSP is antiquated. Java itself, outside of a JSP, is alive and kicking.

Java code belongs in Java classes. It does not belong in a (modern) JSP.

Tomcat does sometimes swap the authentication tokens between sessions and no information or ideas about how to go about debugging this.

No, Tomcat doesn't. It must be something in your code.

I would start with cleaning it up as outlined earlier (remove new session check and extraneous cast). Then we can talk about how to further diagnose this.

[Joel Sander]

Bear Bibeault wrote:

Joel Sander wrote:Interesting and informative. I'll look into filters. Thanks! Are you saying that using Java to create server content is completely antiquated? Does that mean that all modern servers use php?

No. I said using Java in a JSP is antiquated. Java itself, outside of a JSP, is alive and kicking.

Java code belongs in Java classes. It does not belong in a (modern) JSP.

Tomcat does sometimes swap the authentication tokens between sessions and no information or ideas about how to go about debugging this.

No, Tomcat doesn't. It must be something in your code.

I would start with cleaning it up as outlined earlier (removed new session check and extraneous cast). Then we can talk about how to further diagnose this.

Thanks for clarifying on the code belonging in Java classes. 98% of my code is in classes.
---
I can remove the session check; that will take about a week since this is a weekend/evenings project. I'll post back when I've finished that.

The cast I think you are talking about is this one: (UserToken)session.getValue("uToken"). It is required by Java's syntax. The pages won't compile without it, so I must be misunderstanding you somehow again.

[Bear Bibeault]

Mixing the assignment within the condition is a bad practice. You need the cast for the assignment. Refactor the code to assign before doing the check.

[Joel Sander]

Bear Bibeault wrote:Mixing the assignment within the condition is a bad practice. You need the cast for the assignment. Refactor the code to assign before doing the check.

Let me see if I understand. Is this what you are suggesting:

<%
   UserToken userToken = (UserToken)session.getValue("uToken");
   if ( userToken == null ) {
%>
      <%@ include file="Timeout.jsp" %>
      //response.sendRedirect("logout.jsp");
<%
  } else {
      // Do the webpage stuff here
  }
%>

[Bear Bibeault]

Better. But I'd still refactor out of the JSPs so that code exists exactly once in the web app.

Also, getValue() is deprecated and shouldn't be used.