Good thoughts Wendy. Thanks for the tips. Just trying to wrap my head
around struts and I see your point on the action vs actionForward. I
probably muddled it, but the Action us where I am attempting this.
No, I have no good reason to NOT use datasource. That sounds like a
reasonable route. Just following this line of thought as I'm thinking
"OK..there maybe some other parameters I need access to".....
So, let's assume I have some other configuration data I need access
to.....
I understand the getServlet() from the action. What I have created is
an interface...lets call it authinterface and then implemented that in
an Authorization class. In the Action, I create an Authorization object
and pass it my parameters, username, password, dbusername, dbpassword,
dburl.
So:
Authorization auth = new Authentication();
boolean isAllowed = auth.authenticate(user,pass, dbuser,dbpass, host);
Something like that from the action.
Forgive my ignorance on this one, but when you say "I would not tie
data access to the Servlet spec." have I done that above? I assume
that's not best practice?
Thanks much for your comments and willingness to help out!!
-Aaron
> I understand the getServlet() from the action. What I have created is
> an interface...lets call it authinterface and then implemented that in
> an Authorization class. In the Action, I create an Authorization object
> and pass it my parameters, username, password, dbusername, dbpassword,
> dburl.
I would have the Authentication object "know" how to talk to the database.
This part of the webapp doesn't even need to know that there *is* a
database, it only needs to ask, "Is this person who he says he is?" and "Can
this person see this page?"
If you configure a DataSource, your Authentication object can "look up" the
connection and not worry about how to connect. Then you just pass in the
userid/password pair your user typed in, and get back a response.
> Forgive my ignorance on this one, but when you say "I would not tie
> data access to the Servlet spec." have I done that above?
Yes, by putting the database userid and password in as init params, now your
auth code depends on things like 'ServletContext' in order to get those
values.
You're reinventing the wheel here... there are already authorization and
authentication schemes built into the Servlet spec. Are you sure they won't
work for you? If you haven't already, take a look at SRV.12 of the Servlet
2.3 Specification before you go too much further.

Signature
Wendy Smoak
Guy Noir - 24 May 2005 00:41 GMT
Thanks much for the response. Agreed. As to using the built in
authentication, I am attempting to build a portal that will allow
instaneous access without modifying system files, so I'm MD5 hashing
passwords and storing them in the SQL backend.
So, I understand how to create the datasource. Now assume that I am
writing a Swing front end and moving to it instead of the web based,
how could I replicate that datasource object?
Sorry for the basic questions...I'm just trying to get up to speed with
the Java way after developing with perl and php for years.....
Thanks Much!!!
-Aaron
Wendy Smoak - 24 May 2005 01:05 GMT
> So, I understand how to create the datasource. Now assume that I am
> writing a Swing front end and moving to it instead of the web based,
> how could I replicate that datasource object?
>
> Sorry for the basic questions...I'm just trying to get up to speed with
> the Java way after developing with perl and php for years.....
You might want to start a new thread about that... I don't actually use
DataSource because I don't use JDBC to connect to my database. Or see if
this helps:
http://java.sun.com/j2se/1.5.0/docs/guide/jdbc/getstart/GettingStartedTOC.fm.html
(Chapter 4 is about DataSource)

Signature
Wendy Smoak
Guy Noir - 24 May 2005 14:59 GMT
Excellent. That's a piece of the JDBC I was never made aware of. I'm
assuming because all of the books that I read that include JDBC always
use URL's rather then a datasource. Excellent help and thanks again
Wendy!
-Aaron