tags:

views:

31

answers:

1

We have a generic JSF 1.1 (myfaces 1.1.4, tomahawk 1.1.9, uses "*.jsf" to map to jsp files) where we need a more flexible way to handle user logins. The basic issue is that the application as such does not know which backend the user needs to connect to, and that has until now been added as a parameter to the URL to the generic login page.

This has proven to be error prone, so I am investigating if we in addition to

<servlet-mapping>
    <servlet-name>Faces Servlet</servlet-name>
    <url-pattern>*.jsf</url-pattern>
</servlet-mapping>

can make a path mapping from "/login/*" so that we can have "/login/foo" and "/login/bar" as plain, robust URLs.

For this to work, I need to have them all map to the same underlying JSP file, which then must be able to identify if "foo" or "bar" was used so we can present backbone specific CSS attributes in the login page branding it accordingly. The environment specific information is located in a property file available to the login page.

I have read through the JSF 1.2 specification but it is a pretty big haystack and I didn't see the needle.

Can this be done in a standard way? (i.e. implementation independent) Can it be done if I upgrade to Mojarra with Tomahawk?

Am I missing something obvious?

+1  A: 

This lies outside the responsibility of JSF. To the point, you'll need a Filter which listens on an url-pattern of /login/*, extracts the path part from it and forwards the request to for example "/login.jsf?path=" + path.

You can either homegrow one or reuse one.

BalusC
There must be a mapping from URL to JSP inside JSF. The "login.jsf?foo=bar" approach is exactly what I want to get away from.
Thorbjørn Ravn Andersen
Well, it's either that, or upgrading to JSF 2.0 which has a much better `GET` support. By the way, if your main concern is actually avoiding to clutter the bean code to process `GET` request parameters, then you can set the `path` request parameter as in the given example as managed bean property transparently using `<managed-property>` in `faces-config.xml` with a `<value>` of `#{param.path}`.
BalusC
By the way, thinking once more about this, do you know the difference between a forward (which I already tried to *emphasize* right in my answer) and a redirect? With a forward, the change in URL is **not reflected** in browser address bar and that seems more to be your main concern.
BalusC
Upgrading to JSF 2.0 is feasible if there is sufficient reason for it. My main concern is that the GET parameters have in the past been fragile which may have been fixed in newer versions than we use, and your forward suggestion (I know the difference to redirect) may encapsulate it well enough to make it work better for us.
Thorbjørn Ravn Andersen