Hi Paul,
I can't help you with the "working around the broken forward directive"
part, as I don't use JaWS. I'm using JRun as I need the forward
directive and the extends directive to work because of my login control
approach. It's a little soon to show it to everybody, but I would give
you the general idea:
To protect the applications that consist of a set of servlets/JSP pages,
I've created a general framework where you can define your security
policy independently of your servlets/JSP pages and where you can
"secure" your application servlets/JSP pages in a couple of simple
steps. The arquitecture is inspired by the MVC approach, here you define
a SecurityModel that will be used to mantain security, and, inspired by
JDBC and it's drivers, you are also allowed to decide which
implementation you want to use for your security model, in runtime.
To secure a servlet/JSP page you just have to follow perform three steps
which basically mean extending a basic secured class(that's the reason I
needed the extends directive) and providing some information to the
architecture so it knows how to protect your servlet/JSP. It uses
forwarding to redirect requests in case access is not allowed, as you
suggested.
We decided to start with a low client requirement approach so right now
we don't use sessions to authenticate requests. We wanted to avoid
forcing the users to have cookies allowed and URL rewriting is sometimes
not an option, so we have started using http-authentication. However,
next step we are planning to implement is to do the same thing with
sessions and allow the client to use one of the options almost
transparently.
Rigth now, the first implementation works like a charm in a real life
project inside our organization. If I can convince my boss to let me do
so, I was planning to turn this project into a Free Source one, but it
still is a bit too soon and I still have to be given permission to go
public. At the moment, documentation, examples and some articles are
being written. If I'm allowed to, I had planned to release the first
beta before the end of the summer, along with the documentation and the
code samples.
I'm sorry I can't give you more information now, but if anybody is
interested I'll keep you informed.
Regards,
Dan
-------------------------------------------
Daniel Lopez Janariz ([EMAIL PROTECTED])
Web Services
Computer Center
Balearic Islands University
-------------------------------------------
Paul Reiber wrote:
>
> Hello, JSP-ers!
>
> I'm interested in how people have worked around the broken "forward"
> directive in Sun's JaWS-based JSP (JSP1.0 beta in the JaWS 2.0 beta, as I
> remember) ...specifically in handling "logging in".
>
> I'd like to have my JSP pages include a "standard" 1-2-or-3-liner near the
> top that calls something (on the order of "sessionBean.verify(request)) to
> ensure that the user gets sent to a login page if they haven't yet got a
> "user" bean instantiated in their session.
>
> I'd also like the user to be able to bookmark any page, and then return
> there days later; returning would involve getting detoured through the
> login page first, and then returned to the original (bookmarked) URL after
> entering a user-id and password. That same "sessionBean.verify(request)"
> call would realize that it should use the username and password from the
> request to try to get a userBean [via some back-end prepared to
> authenticate users]
>
> All in all, this seems like it'd be a simple yet sufficient login approach,
> if forward worked. Is anyone willing to share the general approach,
> infrastructure, or even the code you've used to handle user authentication?
>
> I don't need, or want to know, the low-level "password matching" part, only
> the organization of the clients of that authentication part.
>
> Regards, and thanks in advance!
> -Paul
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
