Win a copy of Practical SVG this week in the HTML/CSS/JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Conditional Welcome-Page

 
Pascal Lochmann
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

i have a simple Problem, but i don't see the easy or "right" solution.

I need to navigate a User for the first page on condition of is role/rights!


The user is authenticated by a third-party SSO and is navigated to my application. The follwing code is what i want to do:




Possible things i tested are:

- A phase listener (Seems much overhead for ONE call)
- Sending to a gernic welcome-page and manipulate the response (ExternelContext->redirect)

None of this solutions "feel" right! Any suggestions? Thanks for your help!

(JSF 1.2)
 
Brendan Healey
Ranch Hand
Posts: 218
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Try this:



[Edit: sorry I just saw that you're using JSF 1.2 and couldn't comment on whether this is
valid on that version but it's got to be worth a go - good luck]

Regards,
Brendan.
 
Tim Holloway
Bartender
Posts: 18419
60
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Usually, a third-party SSO means that you're using container-managed security.

Container-managed security doesn't signal logon events and it doesn't route to a "welcome page". For the first case, that's because you might have logged in hours ago onto a different application on an SSO system, and that state will then apply to all other apps until you log out. For the second case, I happen to like it because it allows me to bookmark secured pages.

However, allowing for those limitations, you can do what you want and the easiest way is usually to use a servlet filter.

When a request comes in, after it's passed container security, it goes to the servlet filter. The servlet filter can then check the HttpServletRequest user ID against a stored user ID in the HttpSession. If the HttpSession doesn't exist or if there is no user ID stored in it, this is the user's first attempt to access the app after login. If the HttpServletRequest userid is null, the user isn't logged in yet.

In the case of first-entry detection, you can test to see which role(s) the user has and select the appropriate welcome page. The servlet filter can then redirect to that page in the usual way.
 
Pascal Lochmann
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Brendan Healey wrote:Try this:



[Edit: sorry I just saw that you're using JSF 1.2 and couldn't comment on whether this is
valid on that version but it's got to be worth a go - good luck]

Regards,
Brendan.


No, luck with that at JSF 1.2! This would be the solution i searched for. Anyway, thanks for your suggestions.


Tim Holloway wrote:Usually, a third-party SSO means that you're using container-managed security.

Container-managed security doesn't signal logon events and it doesn't route to a "welcome page". For the first case, that's because you might have logged in hours ago onto a different application on an SSO system, and that state will then apply to all other apps until you log out. For the second case, I happen to like it because it allows me to bookmark secured pages.

However, allowing for those limitations, you can do what you want and the easiest way is usually to use a servlet filter.

When a request comes in, after it's passed container security, it goes to the servlet filter. The servlet filter can then check the HttpServletRequest user ID against a stored user ID in the HttpSession. If the HttpSession doesn't exist or if there is no user ID stored in it, this is the user's first attempt to access the app after login. If the HttpServletRequest userid is null, the user isn't logged in yet.

In the case of first-entry detection, you can test to see which role(s) the user has and select the appropriate welcome page. The servlet filter can then redirect to that page in the usual way.


The problem here is, that i need the jsf-bean, which calls services to get more data, to decide what pages should be forward to. I could retrieve the faces-beans in the filter like mentioned in this blog ( http://www.thoughtsabout.net/blog/archives/000033.html ). It's a working solution, so thanks for your post.
 
Brendan Healey
Ranch Hand
Posts: 218
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Does it compile and not work at runtime or just not compile? Actually I just realised that this all depends
on whether you're using Facelets or JSP as the view display layer, which are you using?

Regards,
Brendan.
 
Pascal Lochmann
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It compiles without problems, just not work. (No effect)
 
Brendan Healey
Ranch Hand
Posts: 218
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

What's in your web.xml for this entry:



I'm thinking that perhaps it's necessary to try something like one of the following:

nav.handleNavigation(fc, null, "/faces/loginExpired.xhtml");
nav.handleNavigation(fc, null, "faces/loginExpired.xhtml");
nav.handleNavigation(fc, null, "/loginExpired.xhtml");
nav.handleNavigation(fc, null, "loginExpired.xhtml");

also try with or without the file extension (whatever you are using), and factor in any
additional directory structure you have in your project.

Regards,
Brendan.
 
Tim Holloway
Bartender
Posts: 18419
60
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Pascal Lochmann wrote:
...
The problem here is, that i need the jsf-bean, which calls services to get more data, to decide what pages should be forward to. I could retrieve the faces-beans in the filter like mentioned in this blog ( http://www.thoughtsabout.net/blog/archives/000033.html ). It's a working solution, so thanks for your post.


I'm thinking when you say the "jsf-bean" you means FacesContext. Actually, there's not all that much benefit to using FacesContext if you just want to reference things like backing beans. It's better to simply access them directly.

Aside from everything else, the servlet filter isn't going to have a FacesContext, since the FacesContext isn't a long-term object. It's constructed by the FacesServlet, which won't be invoked until AFTER the pre-process filter has handled the request, and it won't exist at all when you're handling non-JSF URLS such as plain-vanilla JSPs. If you construct your own FacesContext, you can run into issues, since it's not going to be the same FacesContext that the FacesServlet works with, since FacesServlet isn't going to knonw about it, and will construct one of its own.

There's nothing magical about JSF backing-beans other than that JSF will construct and initialize them as needed instead of making you write explicit instantiation code. Once instantiated, the beans are stored in their associated scope objects (HttpSession, HttpServletRequest) the same way manually-constructed session/request/application attributes are and the application will have absolutely no way to tell the difference.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!