bas duijzings

Ranch Hand
+ Follow
since Apr 07, 2004
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by bas duijzings

maybe a bit late, but in addition to my earlier posting,

http://www.theserverside.com/news/thread.tss?thread_id=26247

(and thank lasse for linking in some other question)
19 years ago
a lot of things are out there already,

have a look

http://www.laliluna.de/integration-struts-ejb-tutorial.html

dont know if this is usefull to you
19 years ago
eh, take a look at this article.

still struts is indeed http based, but some sort of integration is possible.
http://javaboutique.internet.com/tutorials/Swing/
19 years ago

I'm not a Tomcat expert, so I can't comment on external tools to add user/id pwd. However, I would agree with you that its not a good idea to keep clear text user info in a flat file.
A better approach is to wire up another security framework (i.e LDAP). I *think* I read that you can wire Tomcat to some other security framework, but a cursory search through the tomcat documentation reveals nothing.



I think i found it in the tomcat 5.5 documentation. This seems to answer my questions. http://jakarta.apache.org/tomcat/tomcat-5.5-doc/realm-howto.html#JDBCRealm
can connect to a database and get the roles from there. So there must be a way to get them encrypted with this as well.

thanks for the pointer.
19 years ago
maybe it is just an extra, but the sample chapter of struts recipes does give more information about how the below can be set up

<!-- these lines handle field 1 --!>

<logic:equal name="user" property="type" value="owner">

<html assword name="oldPassword"/>

</logic:equal>



regardz
baz
19 years ago
wow, that is some chapter. However one thing is a concern on the security part of this. Maybe this is outside the scope of the book, but it would be nice if we could discuss...

The username and password in the tomcat-users.xml are hardcoded and visible to anyone who has access from the inside. To me this sounds like storing unhashed passwords in a flat file which is a danger.
Also how can you add users interactively, are there any tools, api's or do you have to write them yourselves.

To bypass this my solution would be to store the usernames and passwords in the database and get the userrole when the user logs in. This also comes from the database. Then in the processroles you just check if the user has the same role (in the session) as what is needed for an action.

Am I still making sense, anyone wants to comment on this ?
19 years ago
Hi,

Do you describe anything about the requestprocessor, overwriting it etc ? When I look at the table of contents it does not really mention this.

regards,
baz
19 years ago
Hi George and Danilo,

Thanks for joining the Javaranch. Sometimes in other forum's you will get the typical question 'why did you write this book'. However I would like to start off with that question as well since there are so many struts books on the market already. What does make your book special. Is there some content in here that I cannot find in other books ?

regards,
baz
19 years ago
ha, are they evil.
well, depends how you look at it. They can be a nightmare for maintenance, if you have one frame update the other and you wnat to acces data that has changed on one frame in the other. Then you will realize that you need to update a frame and that another needs updating as well. Then what you do is a onload in the body and hey there you go. Now you are in a sliding scale. One frame updates the other and the waterfall starts. Now you reached exactly nothing. The customer will see two or three frames change inexplicably and you as a programmer suddenly dont know where the updates are coming from. And then suddenly they are updating each other in a circle.

And you know what ? One frame is one http request. So if you update two frames you have two http request, going to use the bandwidth. It just takes up time exponentionally if more frames need updating.

do i still make sense ?
19 years ago
whoah, he wasn't just participating. He was practically owning the place.
Thanks hans, you made an example and a benchmark for all future authors. !!
19 years ago
hi,
take one of the sample applications of struts and use this as your starting point. This will already give you a headstart on the learning curve that you will undoubtedly have.
Then depending on your user interface (whether you want a rich user interface or a boring one ;-) you can decide if you want to use jsf. I assume you can plug in jsf at a later date as well and use it only on the places where it adds something. At least take a look at the possibilities of jsf.

Besides this advice, you may want to start the project with a prototype, giving you a few weeks to read up.
19 years ago
oh thomas, that is unfair ! Now nobody will react to this thread...
19 years ago
hi hans.

When I wrote it, the Struts-JSF package wasn't ready, so I only cover it briefly. On the other hand, there's not much needed to use it; change a few class names in the Struts configuration file and use a few new Struts tags in the JSP pages, and Struts takes care of all the dirty work of getting user interface events handled by JSF and backend code invokations handled by Struts Actions.

What I cover in great detail is how to migrate a Struts application to pure JSF; that's what I feel is most important to cover in a JSF book.



then wouldn't it be best to use the best of both worlds ? Use struts as the framework and use jsf for dynamics of gui ?
19 years ago
thanks hans for this elaboration. I just tried to write exactly the same in another thread, since i had the experience of a customer wanting javascript turned off.
thankfully your reply more elaborate than mine, but then again i havent written a book.
19 years ago