It sounds like a reasonable way to approach things. Personally, I use Acegi for security, but it doesn't address your particular use case. It would be an interesting feature to add.
I noticed that Josh Canfield just replied. If that solves your problem, great. I found it difficult initially understanding what I was trying to do with wiring services in AppModule, and it sounds like your UserPermissions object is more of a service. If you are familiar with Spring, then equate a build() method in AppModule with a bean definition in Spring, and contribute() methods are used to build up lists that would be fed to beans for configuration. Although tapestry5-acegi is more filter-based than dispatcher based, you might want to take a look at how the various services were wired together. http://www.localhost.nu/svn/public/tapestry5-acegi The javadocs are at: http://www.localhost.nu/java/tapestry5-acegi/apidocs/overview-tree.html I have a particular fondness for that project, because working through that source code, I finally understood tapestry-ioc and Acegi. Jonathan > -----Original Message----- > From: Nguyen, Michael [mailto:[EMAIL PROTECTED] > Sent: Friday, April 04, 2008 3:09 PM > To: Tapestry users > Subject: RE: accessing requestglobals inside dispatcher and other data > support classes > > The code I uploaded was there to illustrate. I stepped through with a > debugger to find that those instance variables are null once I am inside > any method. I figured that I was doing something wrong so I didn't want > to confuse matters and put references to the objects in the sample. > > Thanks for the clarification on UserPermissions. > However, shouldn't dispatchers have access to the RequestGlobals service > considering it is part of the request processing flow? If not, how do I > obtain the IP address of the user coming in? I intend on validating the > user during the execution of the AccessController Dispatcher. My > intention is to perform user authentication during this process. > > My goal is to provide an authentication mechanism that is transparent to > the pages. The entire application is not accessible unless you are > authenticated. Thus, I want to alleviate the responsibliity of that > away from the page classes. Once a user logs in, he/she should be able > to go anywhere in the application. The dispatcher should determine if > the user has a valid session and direct the user to the appropriate > pages if the user's session expires and somehow handle returning the > user to the current request after successfully logging in. > > The key thing for me is that the remote IP address will be used for IP > authentication. That information is not available through the Request > object. > > Does this make any sense? Am I approaching this the wrong way? > > Thanks, > Michael > > > -----Original Message----- > From: Jonathan Barker [mailto:[EMAIL PROTECTED] > Sent: Friday, April 04, 2008 11:49 AM > To: 'Tapestry users' > Subject: RE: accessing requestglobals inside dispatcher and other data > support classes > > Michael, > > This is not a page class, so Tapestry will not process your injections. > > You also haven't used either of your injected properties, so why are > they there? > > > Jonathan > > > -----Original Message----- > > From: mnguyen21 [mailto:[EMAIL PROTECTED] > > Sent: Friday, April 04, 2008 2:29 PM > > To: users@tapestry.apache.org > > Subject: accessing requestglobals inside dispatcher and other data > > support classes > > > > > > Hi everybody, > > I'm basically starting to learn T5 all over again. I'm trying to > > implement an AccessController based on Chris Lewis' articles and have > > hit a roadblock. > > http://wiki.apache.org/tapestry/Tapestry5HowToCreateADispatcher > > Dispatcher1 > > http://wiki.apache.org/tapestry/Tapestry5HowToCreateADispatcher2 > > Dispatcher2 > > > > I can't seem to access the requestGlobals Service in either the > > dispatcher or any of the User classes. I've tried adding the > > following to each of the > > classes: > > > > @Inject > > @Service("RequestGlobals") > > private RequestGlobals requestGlobals; > > > > Inside the dispatcher I try to create a UserPermissions object. This > > object requires things from the session and request. I thought I > > would try to inject the requestGlobals into the UserPermissions class. > > > The reason I need the RequestGlobals service is that Request does not > > contain the remote IP address of the current request, only the > > HttpServletRequest object does. > > > > Each time this results in a null value for requestGlobals. According > > to the wiki, "RequestGlobals" is a readily available service I should > > just be able to inject into any other page. Am I interpreting this > > wrong? Is there something I need to do in the AppModule class in > > order to make the RequestGlobals service available to my classes? > > > > > > Thanks, > > Michael > > > > btw, I've uploaded a copy of my "UserPermissions" class ( its called > > UserSettings now) for reference. > > > > http://www.nabble.com/file/p16495148/UserSettings.java > > UserSettings.java > > -- > > View this message in context: http://www.nabble.com/accessing- > > requestglobals-inside-dispatcher-and-other-data-support-classes- > > tp16495148p16495148.html > > Sent from the Tapestry - User mailing list archive at Nabble.com. > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
