• Post Reply Bookmark Topic Watch Topic
  • New Topic

Question about how to check for a session  RSS feed

 
Raymond Gillespie
Ranch Hand
Posts: 135
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a question about how to check for a session as the user goes through different pages. I am using Java beans and EL to pass data from page to page but I cannot figure out how to check for a session on the pages without the use of a scriptlet with an if else statement in it.

I do not want the user to be able to access any pages unless they are logged in. With a scriptlet, I can create a statement that says if session exists show name else redirect to login page.

From what I have read and what some of the wonderful members here have told me, scriptlets are a big no no these days. So, how do I do these without the use of a scriptlet?
 
Paul Clapham
Sheriff
Posts: 22185
38
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't see what scriptlets would have to do with it, since they were only used in JSPs. Checking to see if a session existed wouldn't be part of generating the view, so it shouldn't be in a JSP anyway.

But here's what you should do: When the user logs in, the servlet which processes that should create a session (if one doesn't already exist) and put a "UserId" attribute in it. That could contain the user ID, but its main purpose is to show that the user is logged in. Then anything which needs to know whether the user is logged in would just look for that session attribute. Not there? Then the user isn't logged in.

Often this would be done in a filter, so you can redirect to the login page if you need to, but if your JSPs need to display different information to logged-in users then they would just have to check to see if the UserId attribute was present.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65833
134
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Scriptlets are a big no-no. You are wise to avoid them.

But before I answer your specific question, I'm going to tell you that you are doing it wrong. The JSP is the wrong place to be checking for authentication. If you are going to be rolling your own security (Tim, to the white courtesy phone to explain why that's a bad idea), you want to do your checking in a filter. Firstly, that way you don't need to pollute the pages with checks. Secondly, if you have page controllers, and you should, checking for authentication on the pages means that the controllers have already executed. Ooops.

With that all said, you can reference any scoped variable in a session by just naming it in the EL. For example, if there's a scoped variable named "frank" in the session, ${frank) will access it, and ${not null frank} would test for its existence. But you should not be using these for authentication.

[Edit: Paul beat me to it, but I'll leave my own thoughts here as well.]
 
Raymond Gillespie
Ranch Hand
Posts: 135
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Clapham wrote:I don't see what scriptlets would have to do with it, since they were only used in JSPs. Checking to see if a session existed wouldn't be part of generating the view, so it shouldn't be in a JSP anyway.

But here's what you should do: When the user logs in, the servlet which processes that should create a session (if one doesn't already exist) and put a "UserId" attribute in it. That could contain the user ID, but its main purpose is to show that the user is logged in. Then anything which needs to know whether the user is logged in would just look for that session attribute. Not there? Then the user isn't logged in.

Often this would be done in a filter, so you can redirect to the login page if you need to, but if your JSPs need to display different information to logged-in users then they would just have to check to see if the UserId attribute was present.


I get what you are saying here but what if the user tried to access the page directly by typing it into the address bar? In this case a servlet is not being called to process anything, at least it isn't as I have it now.

In the little application that I am working on for practice/learning, if someone tried to access any page without being logged in, I want to be able to redirect them to the log in page.
 
Paul Clapham
Sheriff
Posts: 22185
38
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Raymond Gillespie wrote:I get what you are saying here but what if the user tried to access the page directly by typing it into the address bar? In this case a servlet is not being called to process anything, at least it isn't as I have it now.

In the little application that I am working on for practice/learning, if someone tried to access any page without being logged in, I want to be able to redirect them to the log in page.


Well, first of all your JSP shouldn't be accessible that way at all. They should be under the WEB-INF folder, where they are accessible internally (i.e. your servlets can forward to them) but not externally (i.e. there's no valid URL to refer to them). But anyway if you went with a filter to redirect non-logged-in users to the login page, that filter would apply to JSPs as well as servlets. And there's no reason not to use a filter for that...
 
Raymond Gillespie
Ranch Hand
Posts: 135
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Clapham wrote:
Raymond Gillespie wrote:I get what you are saying here but what if the user tried to access the page directly by typing it into the address bar? In this case a servlet is not being called to process anything, at least it isn't as I have it now.

In the little application that I am working on for practice/learning, if someone tried to access any page without being logged in, I want to be able to redirect them to the log in page.


Well, first of all your JSP shouldn't be accessible that way at all. They should be under the WEB-INF folder, where they are accessible internally (i.e. your servlets can forward to them) but not externally (i.e. there's no valid URL to refer to them). But anyway if you went with a filter to redirect non-logged-in users to the login page, that filter would apply to JSPs as well as servlets. And there's no reason not to use a filter for that...


The JSP files are under WebContent/WEB-INF. Of course everything I am working with is localhost using Tomcat but when I type something into the address bar, it still comes up. Do I have something configured wrong?
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65833
134
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you can bring something up under WEB-INF, then the web app is not configured correctly. Nothing under WEB-INF should be addressable.
 
Raymond Gillespie
Ranch Hand
Posts: 135
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear Bibeault wrote:If you can bring something up under Web-INF, then the web app is not configured correctly. Nothing under WEB-INF should be addressable.


How should be be configured? At this point, all of my JSP files are in that directory, even the login page which is acting as the home page, which should be addressable.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65833
134
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What URL are you using that allows the JSPs under WEB-INF to be served?
 
Raymond Gillespie
Ranch Hand
Posts: 135
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear Bibeault wrote:What URL are you using that allows the JSPs under WEB-INF to be served?


http://localhost:8080/ProjectName/fileName.jsp

When I click run for a JSP file within Eclipse, that is how it comes up in the browser. If type that into the address bar, I can still get to any of the JSP pages
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65833
134
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My advice, which I give to everyone, is step away from the freaking IDE, which doesn't give you a taste for how your app will run in the real world.

Deploy your app to a standalone Tomcat (or other) instance. Use the IDE only as a smart editor, not a run-time environment. It will just lead you stray.
 
Raymond Gillespie
Ranch Hand
Posts: 135
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear Bibeault wrote:My advice, which I give to everyone, is step away from the freaking IDE, which doesn't give you a taste for how your app will run in the real world.

Deploy your app to a standalone Tomcat (or other) instance. Use the IDE only as a smart editor, not a run-time environment. It will just lead you stray.


Unless I am really confused, Tomcat is standalone as it was already installed as part of my XAMPP stack, which I initially installed for Apache and MySQL to use with PHP. When I launch the app, it opens up in my default browser, which is FireFox.

 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65833
134
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you are launching via the IDE you are not using standalone Tomcat by definition.

 
Raymond Gillespie
Ranch Hand
Posts: 135
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Point taken. I have now set it up as stand alone.

So now back to the original question. Some of the JSP files should be still be accessible without having to be called by a servlet. Take for instance I bookmark a page on a website that requires a user to be logged in to reach the page. As long as I am logged in, clicking that bookmark will get me to that page. But if I log out or my session expires, I can't get to that page; instead I am redirected to the log in page. This is what I am shooting for.

And by the way. I found a ton of useful information in the Tomcat directory that I didn't realize was there!
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65833
134
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Raymond Gillespie wrote:Some of the JSP files should be still be accessible without having to be called by a servlet.

No, they should not. The page controller for a page prepares the page for display, without it, the page (in a properly structured web application) will be missing its data.

But that all orthogonal to security, which should be checked by a filter, not the JSP, and not its servlet controller.

But if I log out or my session expires, I can't get to that page; instead I am redirected to the log in page. This is what I am shooting for.

That's what the filter should do for you.
 
Raymond Gillespie
Ranch Hand
Posts: 135
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear Bibeault wrote:
Raymond Gillespie wrote:Some of the JSP files should be still be accessible without having to be called by a servlet.

No, they should not. The page controller for a page prepares the page for display, without it, the page (in a properly structured web application) will be missing its data.


OK. I think I see what you are saying because this is assuming that there are no static pages??
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65833
134
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Obvious question: if the page is completely static, why would it be a JSP versus static HTML?

In any case, security checks should not be made in servlets or pages on an individual basis.

Btw, if you haven't read this article, I'd advise doing so.
 
Raymond Gillespie
Ranch Hand
Posts: 135
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear Bibeault wrote:Obvious question: if the page is completely static, why would it be a JSP versus static HTML?

In any case, security checks should not be made in servlets or pages on an individual basis.

Btw, if you haven't read this article, I'd advise doing so.


Well, I suppose none of them would be completely static because at the very least they should/would show the user name or login ID and the number of selections in the cart, at least for what I am working on.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65833
134
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Right, so not static.

Sure, it could be possible that a JSP needs no data pre-fetching -- a case where the dynamic data is already resident in the session, for example. But for consistency, I always still have a controller even if it doesn't have much to do. It also makes mapping filters easier. YMMV.
 
Raymond Gillespie
Ranch Hand
Posts: 135
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear Bibeault wrote:Right, so not static.

Sure, it could be possible that a JSP needs no data pre-fetching -- a case where the dynamic data is already resident in the session, for example. But for consistency, I always still have a controller even if it doesn't have much to do. It also makes mapping filters easier. YMMV.


Perhaps we can discuss mapping filters then? Looking at a few examples online, I am not making much since of them.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65833
134
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Did you read the article? It's actually a lot easier if you use a front controllers as you only need to map the filter to the URL of the controller. Otherwise, you need to map the individual servlets such that it easy to apply a filter rather than creating a mapping for each and every one.

What specific difficulties are you having?

P.S. Security is hard. It's even harder when the concepts are new. I'd strong suggest either exploring using container security or a package such as Shiro.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!