You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Jose Gonzalez Gomez <jg...@opentechnet.com> on 2003/09/03 00:15:23 UTC
J2EE authentication and authorization
I've searched through the list archives for this, but I haven't been
able to find a definitive answer. The problem is: we'd like to use
Tapestry to build the web layer of an application, but this application
makes intensive use of the J2EE declarative security in its EJB layer,
so we must authenticate the user using the J2EE mechanism (in this case,
form based authentication) to get this security information propagated
to the EJB layer automatically. We'd also like to have some Tapestry
pages protected so only users with some given role are able to access them.
The question is: what's the recommended approach to solve this, if
there is any? Any help would be greatly appreciated, as right now this
is the only important reason that prevents us from choosing Tapestry
instead of Struts.
Thanks in advance, regards
Jose
Re: J2EE authentication and authorization
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Wednesday, September 3, 2003, at 05:45 PM, Jim Frederic wrote:
> I've done exactly this, so yes it will work. Customized engine to
> override getMonitor(ServletContext) to produce a monitor with a
> serviceBegin() method which checks for authentication. The
> ServletContext passed to getMonitor is cached and can be used in
> serviceBegin to get the underlying HttpServletRequest. The
> authentication itself is homemade, not J2EE at all. It throws a
> PageRedirectException if the user is not permitted.
Nice! I'm glad I'm not crazy after all. (boy it sure is nice using
IntelliJ to surf through the Tapestry code to get a handle on it)
I guess next up is inventing some way to associate direct links and
roles and all is set.
What other things are people doing with custom monitors?
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: J2EE authentication and authorization
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Wednesday, September 3, 2003, at 05:45 PM, Jim Frederic wrote:
> I've done exactly this, so yes it will work. Customized engine to
> override getMonitor(ServletContext) to produce a monitor with a
> serviceBegin() method which checks for authentication. The
> ServletContext passed to getMonitor is cached and can be used in
> serviceBegin to get the underlying HttpServletRequest. The
> authentication itself is homemade, not J2EE at all. It throws a
> PageRedirectException if the user is not permitted.
Nice! I'm glad I'm not crazy after all. (boy it sure is nice using
IntelliJ to surf through the Tapestry code to get a handle on it)
I guess next up is inventing some way to associate direct links and
roles and all is set.
What other things are people doing with custom monitors?
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: J2EE authentication and authorization
Posted by Jim Frederic <ji...@isogen.com>.
I've done exactly this, so yes it will work. Customized engine to
override getMonitor(ServletContext) to produce a monitor with a
serviceBegin() method which checks for authentication. The
ServletContext passed to getMonitor is cached and can be used in
serviceBegin to get the underlying HttpServletRequest. The
authentication itself is homemade, not J2EE at all. It throws a
PageRedirectException if the user is not permitted.
-Jim
Erik Hatcher wrote:
> This may be a hack or crazy, but digging into the code I've come up
> with this idea (figured I'd mail it out while it was fresh and get
> feedback).
>
> Implement an IMonitor class that has security blocking logic in
> serviceBegin, which takes the service name and request URI making it
> possible to do the right checks on direct links, which is what a menu
> would consist of. If the user is not allowed to get to that URI then
> throw some type of exception (PageRedirectException,
> RedirectException, or...??).
>
> Is this at all sensical? Could a custom monitor get at the
> HttpServletRequest? (well, it could if you also override getMonitor
> in the engine)
>
> Thoughts?
>
> Also, has anyone implemented a component that simply is a condition
> based on a specified list of allowed roles? If the user is in the
> list of roles, then render the body, otherwise not.
>
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: J2EE authentication and authorization
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
This may be a hack or crazy, but digging into the code I've come up
with this idea (figured I'd mail it out while it was fresh and get
feedback).
Implement an IMonitor class that has security blocking logic in
serviceBegin, which takes the service name and request URI making it
possible to do the right checks on direct links, which is what a menu
would consist of. If the user is not allowed to get to that URI then
throw some type of exception (PageRedirectException, RedirectException,
or...??).
Is this at all sensical? Could a custom monitor get at the
HttpServletRequest? (well, it could if you also override getMonitor in
the engine)
Thoughts?
Also, has anyone implemented a component that simply is a condition
based on a specified list of allowed roles? If the user is in the list
of roles, then render the body, otherwise not.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: J2EE authentication and authorization
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Wednesday, September 3, 2003, at 03:01 PM, Howard M. Lewis Ship
wrote:
> Tapestry is expressly design to support multiple Tapestry apps (with
> multiple servlets) within the
> same WAR.
>
> So, you could have
>
> /context/app1/app, /context/app1/Home.html and /WEB-INF/app1/Home.page
> (and
> /WEB-INF/app1/app1.application)
> /context/app2/app, /context/app2/Home.html, /WEB-INF/app2/Home.page,
> /WEB-INF/app2/app2.application
This was my understanding from looking at the code as well, so thanks
for validating that I'm understanding it.
>> At this point I have not identified exactly how we need J2EE security
>> integration with Tapestry, but it would be nice to have a menu
>> component that was role-based intelligent such that links not
>> accessible to certain roles are not shown if the user is not in those
>> roles and to restrict direct access to pages that are not allowed. I
>> welcome any advice on how folks have done this already or how
>> one might
>> go about doing this type of thing.
>
> Again, J2EE auth doesn't seem to have this (ability to query ahead of
> time); perhaps we need
> something appserver-specific that knows how to get at the raw
> declartive security data.
I'm not proposing any kind of "query ahead". I'm thinking of a
component that can get at the HttpServletRequest and do an
isUserInRole() call at render-time and then only display menu items
associated with a particular role.
The question becomes how to associate roles with pages and hyperlinks?
I'm guessing that a custom IEngine implementation could consult some
mapping of pages/roles and do the right thing before passing on to the
services, right?
Erik
p.s. Speaking of a custom engine... my first Tapestry success was
implementing a custom engine and message resources implementation to
use the resources from a database table. Works very nicely!
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: J2EE authentication and authorization
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
> -----Original Message-----
> From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
> Sent: Wednesday, September 03, 2003 2:21 PM
> To: Tapestry users
> Subject: Re: J2EE authentication and authorization
>
>
> I too am intensely interested in Tapestry in a J2EE security
> context.
> I am actually in the process of putting this type of thing in to our
> first Tapestry project.
>
> On Wednesday, September 3, 2003, at 01:17 PM, Jose Gonzalez Gomez
> wrote:
> > So what should have Tapestry in order to be compatible with the
> > J2EE model? Just some way to control URLs. Just think you
> could group
> > some pages under, let's say, an area of the application,
> and Tapestry
> > could generate URLs for that pages this way: "/vlib/app/area". With
> > only this modification you could use the declarative
> security model of
> > J2EE. In Struts you can do this using modules and/or action
> mappings.
>
> What about having other "applications" within the same WAR? I'm
> assuming this works fine with Tapestry as it seems to be geared for
> this. Then you could isolate by URL space as you mentioned.
> Our last
> project was in Struts and we did exactly this too.
>
> What are the pros/cons to having multiple Tapestry
> ApplicationServlet's
> registered to different URL's??
Tapestry is expressly design to support multiple Tapestry apps (with multiple servlets) within the
same WAR.
So, you could have
/context/app1/app, /context/app1/Home.html and /WEB-INF/app1/Home.page (and
/WEB-INF/app1/app1.application)
/context/app2/app, /context/app2/Home.html, /WEB-INF/app2/Home.page, /WEB-INF/app2/app2.application
(servlet, Home page template, Home page spec, application spec)
and so forth.
Each application will have its own Visit and Global, own pool of Engines, own everything. The
HttpSession keys all include the applications name (i.e., "app1" or "app2").
These apps could communicate with each other by storing HttpSession keys explicitly.
>
> > Please take this as constructive criticism, as I think
> that having
> > this feature would be of great value for applications
> wanting to use
> > the J2EE web security model. Anyway, I don't know if adding
> this would
> > be complicated. Maybe if I have time I can take a look at Tapestry
> > sources and try it myself... any advice?
>
> Its a must-have feature for us to be able to integrate our
> application
> within J2EE security as well. We have session beans that are
> restricted to specific roles and despite the well documented
> drawbacks
> to J2EE security it is sufficient for our needs.
>
> At this point I have not identified exactly how we need J2EE security
> integration with Tapestry, but it would be nice to have a menu
> component that was role-based intelligent such that links not
> accessible to certain roles are not shown if the user is not in those
> roles and to restrict direct access to pages that are not allowed. I
> welcome any advice on how folks have done this already or how
> one might
> go about doing this type of thing.
Again, J2EE auth doesn't seem to have this (ability to query ahead of time); perhaps we need
something appserver-specific that knows how to get at the raw declartive security data.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: J2EE authentication and authorization
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
I too am intensely interested in Tapestry in a J2EE security context.
I am actually in the process of putting this type of thing in to our
first Tapestry project.
On Wednesday, September 3, 2003, at 01:17 PM, Jose Gonzalez Gomez
wrote:
> So what should have Tapestry in order to be compatible with the
> J2EE model? Just some way to control URLs. Just think you could group
> some pages under, let's say, an area of the application, and Tapestry
> could generate URLs for that pages this way: "/vlib/app/area". With
> only this modification you could use the declarative security model of
> J2EE. In Struts you can do this using modules and/or action mappings.
What about having other "applications" within the same WAR? I'm
assuming this works fine with Tapestry as it seems to be geared for
this. Then you could isolate by URL space as you mentioned. Our last
project was in Struts and we did exactly this too.
What are the pros/cons to having multiple Tapestry ApplicationServlet's
registered to different URL's??
> Please take this as constructive criticism, as I think that having
> this feature would be of great value for applications wanting to use
> the J2EE web security model. Anyway, I don't know if adding this would
> be complicated. Maybe if I have time I can take a look at Tapestry
> sources and try it myself... any advice?
Its a must-have feature for us to be able to integrate our application
within J2EE security as well. We have session beans that are
restricted to specific roles and despite the well documented drawbacks
to J2EE security it is sufficient for our needs.
At this point I have not identified exactly how we need J2EE security
integration with Tapestry, but it would be nice to have a menu
component that was role-based intelligent such that links not
accessible to certain roles are not shown if the user is not in those
roles and to restrict direct access to pages that are not allowed. I
welcome any advice on how folks have done this already or how one might
go about doing this type of thing.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: J2EE authentication and authorization
Posted by Geoff Longman <gl...@intelligentworks.com>.
By "partition the application into multiple directories" you mean in the way
URLs are generated/handled or are you referring to the physical location of
things?
Had to ask. gulp.
Geoff
----- Original Message -----
From: "Howard M. Lewis Ship" <hl...@comcast.net>
To: "'Tapestry users'" <ta...@jakarta.apache.org>
Sent: Wednesday, September 03, 2003 2:49 PM
Subject: RE: J2EE authentication and authorization
I'm definately moving towards some system to partition the application into
multiple directories; my
primary concern is the proliferation of files in the context root and in
WEB-INF. My main concern is
management of the base URL (without having to resort to the <base> tag,
which can be problematic
behind a firewall).
Once we work out the details, this would allow you to partition the security
constraints on the
application as well. In the vlib example, you could have /vlib/app and
/vlib/Home.html (and
/WEB-INF/Home.page) but also /vlib/admin/app, /vlib/admin/EditUsers.html
(and
/WEB-INF/admin/EditUsers.page).
The problem I'm struggling with involves the base URL when transitioning
from one part of the app to
another.
For example. /vlib/app?service=direct... may activate the EditUsers page and
render the
admin/EditUsers.html template; the base url is still /vlib/ (not
/vlib/admin/) so relative URLs
would be broken. Pretty soon, you're struggling with client redirects and it
gets nasty.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
> -----Original Message-----
> From: Jose Gonzalez Gomez [mailto:jgonzalez@opentechnet.com]
> Sent: Wednesday, September 03, 2003 1:17 PM
> To: Tapestry users
> Subject: Re: J2EE authentication and authorization
>
>
>
> Howard,
>
> I agree with you that the J2EE security model is far from
> perfect,
> but I find it useful in some scenarios, specially when having an EJB
> layer with a domain model and some business rules on top of
> it. In this
> case, as long as the user gets authenticated and this
> security identity
> gets propagated to the EJB layer, I can forget about managing
> security
> (at least a great part of it) and concentrate in another things.
>
> I've been using Struts for quite a while, and lately I've been
> evaluating Tapestry. I would love to move to Tapestry from
> Struts, but
> this lack of integration with the J2EE web security model is
> a stopper
> for me. If I just had this feature I would use Tapestry
> without any doubt.
>
> So what should have Tapestry in order to be compatible
> with the J2EE
> model? Just some way to control URLs. Just think you could group some
> pages under, let's say, an area of the application, and
> Tapestry could
> generate URLs for that pages this way: "/vlib/app/area". With
> only this
> modification you could use the declarative security model of J2EE. In
> Struts you can do this using modules and/or action mappings.
>
> Please take this as constructive criticism, as I think
> that having
> this feature would be of great value for applications wanting
> to use the
> J2EE web security model. Anyway, I don't know if adding this would be
> complicated. Maybe if I have time I can take a look at
> Tapestry sources
> and try it myself... any advice?
>
> Regards
> Jose
>
> Howard M. Lewis Ship wrote:
>
> >I've never been a fan of J2EE security, since it is static and role
> >based. In the applications I've worked on, the same user will have
> >different roles in different contexts. In addition, the
> J2EE security
> >model doesn't support the ability to query what operations
> are allowed
> >within the user's current role ... because a real web
> application will simply not present (or, alternately, visibly
> >disable) fixtures for operations that are not available;
> that just isn't possible unless you can ask
> >the security system what the user can do ... or you have to
> duplicate security data in the
> >presentation layer.
> >
> >Anyway, J2EE security is often based on URL patterns, which
> is also not
> >a good fit for Tapestry, since Tapestry URLs are pretty much fixed
> >("/vlib/app", with different query parameters).
> >
> >Every application I've worked on has used application level security
> >for these reasons; therefore, I've never considered it a
> priority for
> >Tapestry.
> >
> >--
> >Howard M. Lewis Ship
> >Creator, Tapestry: Java Web Components
> >http://jakarta.apache.org/tapestry
> >http://jakarta.apache.org/commons/sandbox/hivemind/
> >http://javatapestry.blogspot.com
> >
> >
> >
> >>-----Original Message-----
> >>From: Jose Gonzalez Gomez [mailto:jgonzalez@opentechnet.com]
> >>Sent: Wednesday, September 03, 2003 11:47 AM
> >>To: Tapestry users
> >>Subject: Re: J2EE authentication and authorization
> >>
> >>
> >>
> >> Howard,
> >>
> >> Any thoughts from you about the J2EE web security
> >>integration would
> >>be greatly appreciated.
> >>
> >> Regards
> >>
> >>Howard M. Lewis Ship wrote:
> >>
> >>
> >>
> >>>This is another reason that we should produce a beta-3 ... it's
> >>>overdue, given that some of the examples in beta-2 don't work.
> >>>
> >>>--
> >>>Howard M. Lewis Ship
> >>>Creator, Tapestry: Java Web Components
> >>>http://jakarta.apache.org/tapestry
> >>>http://jakarta.apache.org/commons/sandbox/hivemind/
> >>>http://javatapestry.blogspot.com
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: dvw3@email.byu.edu [mailto:dvw3@email.byu.edu] On Behalf Of
> >>>>Dan Wells
> >>>>Sent: Wednesday, September 03, 2003 10:45 AM
> >>>>To: Tapestry users
> >>>>Subject: Re: J2EE authentication and authorization
> >>>>
> >>>>
> >>>>I ran into this SAXParseException too. Please see
> >>>>
> >>>>http://article.gmane.org/gmane.comp.java.tapestry.user/2628/ma
> >>>>tch=dan+wells+jboss
> >>>>
> >>>>The important part is this:
> >>>>
> >>>>"To fix the problem, I had to edit the jbosscmp-jdbc.xml and the
> >>>>jboss.xml files for the vlibbeans.jar. They did not have the
> >>>>closing '?' symbol of the <?xml version=.... element on the first
> >>>>line."
> >>>>
> >>>>I hope that helps.
> >>>>
> >>>>On Tue, 2003-09-02 at 16:28, Jose Gonzalez Gomez wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> Bill,
> >>>>>
> >>>>> I haven't... I tried to install it in JBoss 3.0.6, but crimson
> >>>>>complained about some xml file while deploying the application:
> >>>>>
> >>>>> org.xml.sax.SAXParseException: Illegal character
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>">" (>) at
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>end
> >>>>>of XML Declaration.
> >>>>>
> >>>>> Anyway, I'll try to take a look at the sources... can
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>you point me
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>to the place where this is done?
> >>>>>
> >>>>> Thanks a lot, regards
> >>>>> Jose
> >>>>>
> >>>>>Bill Lear wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>On Wednesday, September 3, 2003 at 00:15:23 (+0200)
> Jose Gonzalez
> >>>>>>Gomez writes:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> I've searched through the list archives for this, but
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>I haven't
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>been
> >>>>>>>able to find a definitive answer. The problem is: we'd
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>like to use
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>Tapestry to build the web layer of an application, but
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>this application
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>makes intensive use of the J2EE declarative security in
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>its EJB layer,
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>so we must authenticate the user using the J2EE mechanism
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>(in this case,
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>form based authentication) to get this security
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>information propagated
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>to the EJB layer automatically. We'd also like to have
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>some Tapestry
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>pages protected so only users with some given role are
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>able to access them.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>The question is: what's the recommended approach to
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>solve this, if
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>there is any? Any help would be greatly appreciated, as
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>right now this
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>is the only important reason that prevents us from
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>choosing Tapestry
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>instead of Struts.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>Have you taken a look at the Vlib example?
> >>>>>>
> >>>>>>
> >>>>>>Bill
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>-----------------------------------------------------------
> >>>>>
> >>>>>
> >>----------
> >>
> >>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>To unsubscribe, e-mail:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>tapestry-user-unsubscribe@jakarta.apache.org
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>For additional commands, e-mail:
> >>>>>>tapestry-user-help@jakarta.apache.org
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>------------------------------------------------------------
> >>>>
> >>>>
> >>---------
> >>
> >>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>To unsubscribe, e-mail:
> >>>>>
> >>>>>
> >>tapestry-user-unsubscribe@jakarta.apache.org
> >>
> >>
> >>>>>For additional commands, e-mail:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>tapestry-user-help@jakarta.apache.org
> >>>>--
> >>>>Dan Wells <da...@byu.edu>
> >>>>
> >>>>
> >>>>------------------------------------------------------------
> >>>>
> >>>>
> >>---------
> >>
> >>
> >>>>To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> >>>>For additional commands, e-mail:
> >>>>
> >>>>
> >>tapestry-user-help@jakarta.apache.org
> >>
> >>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>-----------------------------------------------------------
> ----------
> >>>To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail:
> >>>
> >>>
> >>tapestry-user-help@jakarta.apache.org
> >>
> >>
> >>>
> >>>
> >>>
> >>>
> >>------------------------------------------------------------
> ---------
> >>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
> >>
> >>
> >>
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: J2EE authentication and authorization
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
I'm definately moving towards some system to partition the application into multiple directories; my
primary concern is the proliferation of files in the context root and in WEB-INF. My main concern is
management of the base URL (without having to resort to the <base> tag, which can be problematic
behind a firewall).
Once we work out the details, this would allow you to partition the security constraints on the
application as well. In the vlib example, you could have /vlib/app and /vlib/Home.html (and
/WEB-INF/Home.page) but also /vlib/admin/app, /vlib/admin/EditUsers.html (and
/WEB-INF/admin/EditUsers.page).
The problem I'm struggling with involves the base URL when transitioning from one part of the app to
another.
For example. /vlib/app?service=direct... may activate the EditUsers page and render the
admin/EditUsers.html template; the base url is still /vlib/ (not /vlib/admin/) so relative URLs
would be broken. Pretty soon, you're struggling with client redirects and it gets nasty.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
> -----Original Message-----
> From: Jose Gonzalez Gomez [mailto:jgonzalez@opentechnet.com]
> Sent: Wednesday, September 03, 2003 1:17 PM
> To: Tapestry users
> Subject: Re: J2EE authentication and authorization
>
>
>
> Howard,
>
> I agree with you that the J2EE security model is far from
> perfect,
> but I find it useful in some scenarios, specially when having an EJB
> layer with a domain model and some business rules on top of
> it. In this
> case, as long as the user gets authenticated and this
> security identity
> gets propagated to the EJB layer, I can forget about managing
> security
> (at least a great part of it) and concentrate in another things.
>
> I've been using Struts for quite a while, and lately I've been
> evaluating Tapestry. I would love to move to Tapestry from
> Struts, but
> this lack of integration with the J2EE web security model is
> a stopper
> for me. If I just had this feature I would use Tapestry
> without any doubt.
>
> So what should have Tapestry in order to be compatible
> with the J2EE
> model? Just some way to control URLs. Just think you could group some
> pages under, let's say, an area of the application, and
> Tapestry could
> generate URLs for that pages this way: "/vlib/app/area". With
> only this
> modification you could use the declarative security model of J2EE. In
> Struts you can do this using modules and/or action mappings.
>
> Please take this as constructive criticism, as I think
> that having
> this feature would be of great value for applications wanting
> to use the
> J2EE web security model. Anyway, I don't know if adding this would be
> complicated. Maybe if I have time I can take a look at
> Tapestry sources
> and try it myself... any advice?
>
> Regards
> Jose
>
> Howard M. Lewis Ship wrote:
>
> >I've never been a fan of J2EE security, since it is static and role
> >based. In the applications I've worked on, the same user will have
> >different roles in different contexts. In addition, the
> J2EE security
> >model doesn't support the ability to query what operations
> are allowed
> >within the user's current role ... because a real web
> application will simply not present (or, alternately, visibly
> >disable) fixtures for operations that are not available;
> that just isn't possible unless you can ask
> >the security system what the user can do ... or you have to
> duplicate security data in the
> >presentation layer.
> >
> >Anyway, J2EE security is often based on URL patterns, which
> is also not
> >a good fit for Tapestry, since Tapestry URLs are pretty much fixed
> >("/vlib/app", with different query parameters).
> >
> >Every application I've worked on has used application level security
> >for these reasons; therefore, I've never considered it a
> priority for
> >Tapestry.
> >
> >--
> >Howard M. Lewis Ship
> >Creator, Tapestry: Java Web Components
> >http://jakarta.apache.org/tapestry
> >http://jakarta.apache.org/commons/sandbox/hivemind/
> >http://javatapestry.blogspot.com
> >
> >
> >
> >>-----Original Message-----
> >>From: Jose Gonzalez Gomez [mailto:jgonzalez@opentechnet.com]
> >>Sent: Wednesday, September 03, 2003 11:47 AM
> >>To: Tapestry users
> >>Subject: Re: J2EE authentication and authorization
> >>
> >>
> >>
> >> Howard,
> >>
> >> Any thoughts from you about the J2EE web security
> >>integration would
> >>be greatly appreciated.
> >>
> >> Regards
> >>
> >>Howard M. Lewis Ship wrote:
> >>
> >>
> >>
> >>>This is another reason that we should produce a beta-3 ... it's
> >>>overdue, given that some of the examples in beta-2 don't work.
> >>>
> >>>--
> >>>Howard M. Lewis Ship
> >>>Creator, Tapestry: Java Web Components
> >>>http://jakarta.apache.org/tapestry
> >>>http://jakarta.apache.org/commons/sandbox/hivemind/
> >>>http://javatapestry.blogspot.com
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: dvw3@email.byu.edu [mailto:dvw3@email.byu.edu] On Behalf Of
> >>>>Dan Wells
> >>>>Sent: Wednesday, September 03, 2003 10:45 AM
> >>>>To: Tapestry users
> >>>>Subject: Re: J2EE authentication and authorization
> >>>>
> >>>>
> >>>>I ran into this SAXParseException too. Please see
> >>>>
> >>>>http://article.gmane.org/gmane.comp.java.tapestry.user/2628/ma
> >>>>tch=dan+wells+jboss
> >>>>
> >>>>The important part is this:
> >>>>
> >>>>"To fix the problem, I had to edit the jbosscmp-jdbc.xml and the
> >>>>jboss.xml files for the vlibbeans.jar. They did not have the
> >>>>closing '?' symbol of the <?xml version=.... element on the first
> >>>>line."
> >>>>
> >>>>I hope that helps.
> >>>>
> >>>>On Tue, 2003-09-02 at 16:28, Jose Gonzalez Gomez wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> Bill,
> >>>>>
> >>>>> I haven't... I tried to install it in JBoss 3.0.6, but crimson
> >>>>>complained about some xml file while deploying the application:
> >>>>>
> >>>>> org.xml.sax.SAXParseException: Illegal character
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>">" (>) at
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>end
> >>>>>of XML Declaration.
> >>>>>
> >>>>> Anyway, I'll try to take a look at the sources... can
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>you point me
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>to the place where this is done?
> >>>>>
> >>>>> Thanks a lot, regards
> >>>>> Jose
> >>>>>
> >>>>>Bill Lear wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>On Wednesday, September 3, 2003 at 00:15:23 (+0200)
> Jose Gonzalez
> >>>>>>Gomez writes:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> I've searched through the list archives for this, but
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>I haven't
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>been
> >>>>>>>able to find a definitive answer. The problem is: we'd
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>like to use
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>Tapestry to build the web layer of an application, but
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>this application
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>makes intensive use of the J2EE declarative security in
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>its EJB layer,
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>so we must authenticate the user using the J2EE mechanism
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>(in this case,
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>form based authentication) to get this security
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>information propagated
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>to the EJB layer automatically. We'd also like to have
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>some Tapestry
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>pages protected so only users with some given role are
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>able to access them.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>The question is: what's the recommended approach to
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>solve this, if
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>there is any? Any help would be greatly appreciated, as
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>right now this
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>is the only important reason that prevents us from
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>choosing Tapestry
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>instead of Struts.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>Have you taken a look at the Vlib example?
> >>>>>>
> >>>>>>
> >>>>>>Bill
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>-----------------------------------------------------------
> >>>>>
> >>>>>
> >>----------
> >>
> >>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>To unsubscribe, e-mail:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>tapestry-user-unsubscribe@jakarta.apache.org
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>For additional commands, e-mail:
> >>>>>>tapestry-user-help@jakarta.apache.org
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>------------------------------------------------------------
> >>>>
> >>>>
> >>---------
> >>
> >>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>To unsubscribe, e-mail:
> >>>>>
> >>>>>
> >>tapestry-user-unsubscribe@jakarta.apache.org
> >>
> >>
> >>>>>For additional commands, e-mail:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>tapestry-user-help@jakarta.apache.org
> >>>>--
> >>>>Dan Wells <da...@byu.edu>
> >>>>
> >>>>
> >>>>------------------------------------------------------------
> >>>>
> >>>>
> >>---------
> >>
> >>
> >>>>To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> >>>>For additional commands, e-mail:
> >>>>
> >>>>
> >>tapestry-user-help@jakarta.apache.org
> >>
> >>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>-----------------------------------------------------------
> ----------
> >>>To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail:
> >>>
> >>>
> >>tapestry-user-help@jakarta.apache.org
> >>
> >>
> >>>
> >>>
> >>>
> >>>
> >>------------------------------------------------------------
> ---------
> >>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
> >>
> >>
> >>
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: J2EE authentication and authorization
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Wednesday, September 3, 2003, at 02:50 PM, Howard M. Lewis Ship
wrote:
> The other question, something I haven't had time to investage, is
> whether we can do the J2EE
> authentication mapping within Tapestry. I don't know if J2EE provides
> the necessary hooks, but it
> might. We could implement the necessary declarative security inside
> Tapestry, rather than relying on
> the servlet container for it.
I would definitely not recommend this route. It will require
vendor-specific hooks to tie into JAAS appropriately. Look at
OpenSymphony's OSUser project to see how they have done this and other
related things. In fact, I owe it to myself to check it out in more
detail myself. We are devoted to sticking with pure J2EE security
roles for our session beans, so we need that capability in the
presentation tier as well.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: J2EE authentication and authorization
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
The other question, something I haven't had time to investage, is whether we can do the J2EE
authentication mapping within Tapestry. I don't know if J2EE provides the necessary hooks, but it
might. We could implement the necessary declarative security inside Tapestry, rather than relying on
the servlet container for it.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
> -----Original Message-----
> From: Perry Q Hertler [mailto:perry_hertler@yahoo.com]
> Sent: Wednesday, September 03, 2003 2:03 PM
> To: Tapestry users
> Subject: Re: J2EE authentication and authorization
>
>
> I agree with Jose. My number 1 wish for Tapestry is
> J2EE authentication and authorization integration.
>
> --- Jose Gonzalez Gomez <jg...@opentechnet.com>
> wrote:
> >
> > Howard,
> >
> > I agree with you that the J2EE security model is
> > far from perfect,
> > but I find it useful in some scenarios, specially
> > when having an EJB
> > layer with a domain model and some business rules on
> > top of it. In this
> > case, as long as the user gets authenticated and
> > this security identity
> > gets propagated to the EJB layer, I can forget about
> > managing security
> > (at least a great part of it) and concentrate in
> > another things.
> >
> > I've been using Struts for quite a while, and
> > lately I've been
> > evaluating Tapestry. I would love to move to
> > Tapestry from Struts, but
> > this lack of integration with the J2EE web security
> > model is a stopper
> > for me. If I just had this feature I would use
> > Tapestry without any doubt.
> >
> > So what should have Tapestry in order to be
> > compatible with the J2EE
> > model? Just some way to control URLs. Just think you
> > could group some
> > pages under, let's say, an area of the application,
> > and Tapestry could
> > generate URLs for that pages this way:
> > "/vlib/app/area". With only this
> > modification you could use the declarative security
> > model of J2EE. In
> > Struts you can do this using modules and/or action
> > mappings.
> >
> > Please take this as constructive criticism, as I
> > think that having
> > this feature would be of great value for
> > applications wanting to use the
> > J2EE web security model. Anyway, I don't know if
> > adding this would be
> > complicated. Maybe if I have time I can take a look
> > at Tapestry sources
> > and try it myself... any advice?
> >
> > Regards
> > Jose
> >
> > Howard M. Lewis Ship wrote:
> >
> > >I've never been a fan of J2EE security, since it is
> > static and role based. In the applications I've
> > >worked on, the same user will have different roles
> > in different contexts. In addition, the J2EE
> > >security model doesn't support the ability to query
> > what operations are allowed within the user's
> > >current role ... because a real web application
> > will simply not present (or, alternately, visibly
> > >disable) fixtures for operations that are not
> > available; that just isn't possible unless you can
> > ask
> > >the security system what the user can do ... or you
> > have to duplicate security data in the
> > >presentation layer.
> > >
> > >Anyway, J2EE security is often based on URL
> > patterns, which is also not a good fit for Tapestry,
> > >since Tapestry URLs are pretty much fixed
> > ("/vlib/app", with different query parameters).
> > >
> > >Every application I've worked on has used
> > application level security for these reasons;
> > therefore,
> > >I've never considered it a priority for Tapestry.
> > >
> > >--
> > >Howard M. Lewis Ship
> > >Creator, Tapestry: Java Web Components
> > >http://jakarta.apache.org/tapestry
> > >http://jakarta.apache.org/commons/sandbox/hivemind/
> > >http://javatapestry.blogspot.com
> > >
> > >
> > >
> > >>-----Original Message-----
> > >>From: Jose Gonzalez Gomez
> > [mailto:jgonzalez@opentechnet.com]
> > >>Sent: Wednesday, September 03, 2003 11:47 AM
> > >>To: Tapestry users
> > >>Subject: Re: J2EE authentication and authorization
> > >>
> > >>
> > >>
> > >> Howard,
> > >>
> > >> Any thoughts from you about the J2EE web
> > security
> > >>integration would
> > >>be greatly appreciated.
> > >>
> > >> Regards
> > >>
> > >>Howard M. Lewis Ship wrote:
> > >>
> > >>
> > >>
> > >>>This is another reason that we should produce a
> > beta-3 ... it's
> > >>>overdue, given that some of the examples in
> > beta-2 don't work.
> > >>>
> > >>>--
> > >>>Howard M. Lewis Ship
> > >>>Creator, Tapestry: Java Web Components
> > >>>http://jakarta.apache.org/tapestry
> >
> >>>http://jakarta.apache.org/commons/sandbox/hivemind/
> > >>>http://javatapestry.blogspot.com
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>-----Original Message-----
> > >>>>From: dvw3@email.byu.edu
> > [mailto:dvw3@email.byu.edu] On
> > >>>>Behalf Of Dan Wells
> > >>>>Sent: Wednesday, September 03, 2003 10:45 AM
> > >>>>To: Tapestry users
> > >>>>Subject: Re: J2EE authentication and
> > authorization
> > >>>>
> > >>>>
> > >>>>I ran into this SAXParseException too. Please
> > see
> > >>>>
> >
> >>>>http://article.gmane.org/gmane.comp.java.tapestry.user/2628/ma
> > >>>>tch=dan+wells+jboss
> > >>>>
> > >>>>The important part is this:
> > >>>>
> > >>>>"To fix the problem, I had to edit the
> > jbosscmp-jdbc.xml and
> > >>>>the jboss.xml files for the vlibbeans.jar. They
> > did not have
> > >>>>the closing '?' symbol of the <?xml version=....
> > element on
> > >>>>the first line."
> > >>>>
> > >>>>I hope that helps.
> > >>>>
> > >>>>On Tue, 2003-09-02 at 16:28, Jose Gonzalez Gomez
> > wrote:
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>> Bill,
> > >>>>>
> > >>>>> I haven't... I tried to install it in JBoss
> > 3.0.6, but crimson
> > >>>>>complained about some xml file while deploying
> > the application:
> > >>>>>
> > >>>>> org.xml.sax.SAXParseException: Illegal
> > character
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>">" (>) at
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>end
> > >>>>>of XML Declaration.
> > >>>>>
> > >>>>> Anyway, I'll try to take a look at the
> > sources... can
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>you point me
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>to the place where this is done?
> > >>>>>
> > >>>>> Thanks a lot, regards
> > >>>>> Jose
> > >>>>>
> > >>>>>Bill Lear wrote:
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>On Wednesday, September 3, 2003 at 00:15:23
> > (+0200) Jose Gonzalez
> > >>>>>>Gomez writes:
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>> I've searched through the list archives for
> > this, but
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>I haven't
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>>>been
> > >>>>>>>able to find a definitive answer. The problem
> > is: we'd
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>like to use
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>>>Tapestry to build the web layer of an
> > application, but
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>this application
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>>>makes intensive use of the J2EE declarative
> > security in
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>its EJB layer,
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>>>so we must authenticate the user using the
> > J2EE mechanism
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>(in this case,
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>>>form based authentication) to get this
> > security
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>information propagated
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>>>to the EJB layer automatically. We'd also
> > like to have
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>some Tapestry
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>>>pages protected so only users with some given
> > role are
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>able to access them.
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>>>The question is: what's the recommended
> > approach to
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>solve this, if
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>>>there is any? Any help would be greatly
> > appreciated, as
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>right now this
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>>>is the only important reason that prevents us
> > from
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>choosing Tapestry
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>>>instead of Struts.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>Have you taken a look at the Vlib example?
> > >>>>>>
> > >>>>>>
> > >>>>>>Bill
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> >
> >>>>>-----------------------------------------------------------
> > >>>>>
> > >>>>>
> > >>----------
> > >>
> > >>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>To unsubscribe, e-mail:
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>tapestry-user-unsubscribe@jakarta.apache.org
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>>For additional commands, e-mail:
> > >>>>>>tapestry-user-help@jakarta.apache.org
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> >
> >>>>------------------------------------------------------------
> > >>>>
> > >>>>
> > >>---------
> > >>
> > >>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>To unsubscribe, e-mail:
> > >>>>>
> > >>>>>
> > >>tapestry-user-unsubscribe@jakarta.apache.org
> > >>
> > >>
> > >>>>>For additional commands, e-mail:
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>tapestry-user-help@jakarta.apache.org
> > >>>>--
> > >>>>Dan Wells <da...@byu.edu>
> > >>>>
> > >>>>
> >
> >>>>------------------------------------------------------------
> > >>>>
> > >>>>
> > >>---------
> > >>
> > >>
> > >>>>To unsubscribe, e-mail:
> > tapestry-user-unsubscribe@jakarta.apache.org
> > >>>>For additional commands, e-mail:
> > >>>>
> > >>>>
> > >>tapestry-user-help@jakarta.apache.org
> > >>
> > >>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> >
> >>>-----------------------------------------------------------
> ----------
> > >>>To unsubscribe, e-mail:
> > tapestry-user-unsubscribe@jakarta.apache.org
> > >>>For additional commands, e-mail:
> > >>>
> > >>>
> > >>tapestry-user-help@jakarta.apache.org
> > >>
> > >>
> > >>>
> > >>>
> > >>>
> > >>>
> >
> >>------------------------------------------------------------
> ---------
> > >>To unsubscribe, e-mail:
> > tapestry-user-unsubscribe@jakarta.apache.org
> > >>For additional commands, e-mail:
> > tapestry-user-help@jakarta.apache.org
> > >>
> > >>
> > >>
> > >
> > >
> >
> >---------------------------------------------------------------------
> > >To unsubscribe, e-mail:
> > tapestry-user-unsubscribe@jakarta.apache.org
> > >For additional commands, e-mail:
> > tapestry-user-help@jakarta.apache.org
> > >
> > >
> > >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > tapestry-user-help@jakarta.apache.org
> >
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design
> software http://sitebuilder.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: J2EE authentication and authorization
Posted by Perry Q Hertler <pe...@yahoo.com>.
I agree with Jose. My number 1 wish for Tapestry is
J2EE authentication and authorization integration.
--- Jose Gonzalez Gomez <jg...@opentechnet.com>
wrote:
>
> Howard,
>
> I agree with you that the J2EE security model is
> far from perfect,
> but I find it useful in some scenarios, specially
> when having an EJB
> layer with a domain model and some business rules on
> top of it. In this
> case, as long as the user gets authenticated and
> this security identity
> gets propagated to the EJB layer, I can forget about
> managing security
> (at least a great part of it) and concentrate in
> another things.
>
> I've been using Struts for quite a while, and
> lately I've been
> evaluating Tapestry. I would love to move to
> Tapestry from Struts, but
> this lack of integration with the J2EE web security
> model is a stopper
> for me. If I just had this feature I would use
> Tapestry without any doubt.
>
> So what should have Tapestry in order to be
> compatible with the J2EE
> model? Just some way to control URLs. Just think you
> could group some
> pages under, let's say, an area of the application,
> and Tapestry could
> generate URLs for that pages this way:
> "/vlib/app/area". With only this
> modification you could use the declarative security
> model of J2EE. In
> Struts you can do this using modules and/or action
> mappings.
>
> Please take this as constructive criticism, as I
> think that having
> this feature would be of great value for
> applications wanting to use the
> J2EE web security model. Anyway, I don't know if
> adding this would be
> complicated. Maybe if I have time I can take a look
> at Tapestry sources
> and try it myself... any advice?
>
> Regards
> Jose
>
> Howard M. Lewis Ship wrote:
>
> >I've never been a fan of J2EE security, since it is
> static and role based. In the applications I've
> >worked on, the same user will have different roles
> in different contexts. In addition, the J2EE
> >security model doesn't support the ability to query
> what operations are allowed within the user's
> >current role ... because a real web application
> will simply not present (or, alternately, visibly
> >disable) fixtures for operations that are not
> available; that just isn't possible unless you can
> ask
> >the security system what the user can do ... or you
> have to duplicate security data in the
> >presentation layer.
> >
> >Anyway, J2EE security is often based on URL
> patterns, which is also not a good fit for Tapestry,
> >since Tapestry URLs are pretty much fixed
> ("/vlib/app", with different query parameters).
> >
> >Every application I've worked on has used
> application level security for these reasons;
> therefore,
> >I've never considered it a priority for Tapestry.
> >
> >--
> >Howard M. Lewis Ship
> >Creator, Tapestry: Java Web Components
> >http://jakarta.apache.org/tapestry
> >http://jakarta.apache.org/commons/sandbox/hivemind/
> >http://javatapestry.blogspot.com
> >
> >
> >
> >>-----Original Message-----
> >>From: Jose Gonzalez Gomez
> [mailto:jgonzalez@opentechnet.com]
> >>Sent: Wednesday, September 03, 2003 11:47 AM
> >>To: Tapestry users
> >>Subject: Re: J2EE authentication and authorization
> >>
> >>
> >>
> >> Howard,
> >>
> >> Any thoughts from you about the J2EE web
> security
> >>integration would
> >>be greatly appreciated.
> >>
> >> Regards
> >>
> >>Howard M. Lewis Ship wrote:
> >>
> >>
> >>
> >>>This is another reason that we should produce a
> beta-3 ... it's
> >>>overdue, given that some of the examples in
> beta-2 don't work.
> >>>
> >>>--
> >>>Howard M. Lewis Ship
> >>>Creator, Tapestry: Java Web Components
> >>>http://jakarta.apache.org/tapestry
>
>>>http://jakarta.apache.org/commons/sandbox/hivemind/
> >>>http://javatapestry.blogspot.com
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: dvw3@email.byu.edu
> [mailto:dvw3@email.byu.edu] On
> >>>>Behalf Of Dan Wells
> >>>>Sent: Wednesday, September 03, 2003 10:45 AM
> >>>>To: Tapestry users
> >>>>Subject: Re: J2EE authentication and
> authorization
> >>>>
> >>>>
> >>>>I ran into this SAXParseException too. Please
> see
> >>>>
>
>>>>http://article.gmane.org/gmane.comp.java.tapestry.user/2628/ma
> >>>>tch=dan+wells+jboss
> >>>>
> >>>>The important part is this:
> >>>>
> >>>>"To fix the problem, I had to edit the
> jbosscmp-jdbc.xml and
> >>>>the jboss.xml files for the vlibbeans.jar. They
> did not have
> >>>>the closing '?' symbol of the <?xml version=....
> element on
> >>>>the first line."
> >>>>
> >>>>I hope that helps.
> >>>>
> >>>>On Tue, 2003-09-02 at 16:28, Jose Gonzalez Gomez
> wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> Bill,
> >>>>>
> >>>>> I haven't... I tried to install it in JBoss
> 3.0.6, but crimson
> >>>>>complained about some xml file while deploying
> the application:
> >>>>>
> >>>>> org.xml.sax.SAXParseException: Illegal
> character
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>">" (>) at
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>end
> >>>>>of XML Declaration.
> >>>>>
> >>>>> Anyway, I'll try to take a look at the
> sources... can
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>you point me
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>to the place where this is done?
> >>>>>
> >>>>> Thanks a lot, regards
> >>>>> Jose
> >>>>>
> >>>>>Bill Lear wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>On Wednesday, September 3, 2003 at 00:15:23
> (+0200) Jose Gonzalez
> >>>>>>Gomez writes:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> I've searched through the list archives for
> this, but
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>I haven't
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>been
> >>>>>>>able to find a definitive answer. The problem
> is: we'd
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>like to use
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>Tapestry to build the web layer of an
> application, but
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>this application
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>makes intensive use of the J2EE declarative
> security in
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>its EJB layer,
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>so we must authenticate the user using the
> J2EE mechanism
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>(in this case,
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>form based authentication) to get this
> security
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>information propagated
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>to the EJB layer automatically. We'd also
> like to have
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>some Tapestry
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>pages protected so only users with some given
> role are
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>able to access them.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>The question is: what's the recommended
> approach to
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>solve this, if
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>there is any? Any help would be greatly
> appreciated, as
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>right now this
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>is the only important reason that prevents us
> from
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>choosing Tapestry
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>instead of Struts.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>Have you taken a look at the Vlib example?
> >>>>>>
> >>>>>>
> >>>>>>Bill
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
>
>>>>>-----------------------------------------------------------
> >>>>>
> >>>>>
> >>----------
> >>
> >>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>To unsubscribe, e-mail:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>tapestry-user-unsubscribe@jakarta.apache.org
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>For additional commands, e-mail:
> >>>>>>tapestry-user-help@jakarta.apache.org
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
>
>>>>------------------------------------------------------------
> >>>>
> >>>>
> >>---------
> >>
> >>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>To unsubscribe, e-mail:
> >>>>>
> >>>>>
> >>tapestry-user-unsubscribe@jakarta.apache.org
> >>
> >>
> >>>>>For additional commands, e-mail:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>tapestry-user-help@jakarta.apache.org
> >>>>--
> >>>>Dan Wells <da...@byu.edu>
> >>>>
> >>>>
>
>>>>------------------------------------------------------------
> >>>>
> >>>>
> >>---------
> >>
> >>
> >>>>To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> >>>>For additional commands, e-mail:
> >>>>
> >>>>
> >>tapestry-user-help@jakarta.apache.org
> >>
> >>
> >>>>
> >>>>
> >>>>
> >>>>
>
>>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail:
> >>>
> >>>
> >>tapestry-user-help@jakarta.apache.org
> >>
> >>
> >>>
> >>>
> >>>
> >>>
>
>>---------------------------------------------------------------------
> >>To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
> >>
> >>
> >>
> >
> >
>
>---------------------------------------------------------------------
> >To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
> >
> >
> >
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: J2EE authentication and authorization
Posted by Jose Gonzalez Gomez <jg...@opentechnet.com>.
Howard,
I agree with you that the J2EE security model is far from perfect,
but I find it useful in some scenarios, specially when having an EJB
layer with a domain model and some business rules on top of it. In this
case, as long as the user gets authenticated and this security identity
gets propagated to the EJB layer, I can forget about managing security
(at least a great part of it) and concentrate in another things.
I've been using Struts for quite a while, and lately I've been
evaluating Tapestry. I would love to move to Tapestry from Struts, but
this lack of integration with the J2EE web security model is a stopper
for me. If I just had this feature I would use Tapestry without any doubt.
So what should have Tapestry in order to be compatible with the J2EE
model? Just some way to control URLs. Just think you could group some
pages under, let's say, an area of the application, and Tapestry could
generate URLs for that pages this way: "/vlib/app/area". With only this
modification you could use the declarative security model of J2EE. In
Struts you can do this using modules and/or action mappings.
Please take this as constructive criticism, as I think that having
this feature would be of great value for applications wanting to use the
J2EE web security model. Anyway, I don't know if adding this would be
complicated. Maybe if I have time I can take a look at Tapestry sources
and try it myself... any advice?
Regards
Jose
Howard M. Lewis Ship wrote:
>I've never been a fan of J2EE security, since it is static and role based. In the applications I've
>worked on, the same user will have different roles in different contexts. In addition, the J2EE
>security model doesn't support the ability to query what operations are allowed within the user's
>current role ... because a real web application will simply not present (or, alternately, visibly
>disable) fixtures for operations that are not available; that just isn't possible unless you can ask
>the security system what the user can do ... or you have to duplicate security data in the
>presentation layer.
>
>Anyway, J2EE security is often based on URL patterns, which is also not a good fit for Tapestry,
>since Tapestry URLs are pretty much fixed ("/vlib/app", with different query parameters).
>
>Every application I've worked on has used application level security for these reasons; therefore,
>I've never considered it a priority for Tapestry.
>
>--
>Howard M. Lewis Ship
>Creator, Tapestry: Java Web Components
>http://jakarta.apache.org/tapestry
>http://jakarta.apache.org/commons/sandbox/hivemind/
>http://javatapestry.blogspot.com
>
>
>
>>-----Original Message-----
>>From: Jose Gonzalez Gomez [mailto:jgonzalez@opentechnet.com]
>>Sent: Wednesday, September 03, 2003 11:47 AM
>>To: Tapestry users
>>Subject: Re: J2EE authentication and authorization
>>
>>
>>
>> Howard,
>>
>> Any thoughts from you about the J2EE web security
>>integration would
>>be greatly appreciated.
>>
>> Regards
>>
>>Howard M. Lewis Ship wrote:
>>
>>
>>
>>>This is another reason that we should produce a beta-3 ... it's
>>>overdue, given that some of the examples in beta-2 don't work.
>>>
>>>--
>>>Howard M. Lewis Ship
>>>Creator, Tapestry: Java Web Components
>>>http://jakarta.apache.org/tapestry
>>>http://jakarta.apache.org/commons/sandbox/hivemind/
>>>http://javatapestry.blogspot.com
>>>
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: dvw3@email.byu.edu [mailto:dvw3@email.byu.edu] On
>>>>Behalf Of Dan Wells
>>>>Sent: Wednesday, September 03, 2003 10:45 AM
>>>>To: Tapestry users
>>>>Subject: Re: J2EE authentication and authorization
>>>>
>>>>
>>>>I ran into this SAXParseException too. Please see
>>>>
>>>>http://article.gmane.org/gmane.comp.java.tapestry.user/2628/ma
>>>>tch=dan+wells+jboss
>>>>
>>>>The important part is this:
>>>>
>>>>"To fix the problem, I had to edit the jbosscmp-jdbc.xml and
>>>>the jboss.xml files for the vlibbeans.jar. They did not have
>>>>the closing '?' symbol of the <?xml version=.... element on
>>>>the first line."
>>>>
>>>>I hope that helps.
>>>>
>>>>On Tue, 2003-09-02 at 16:28, Jose Gonzalez Gomez wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> Bill,
>>>>>
>>>>> I haven't... I tried to install it in JBoss 3.0.6, but crimson
>>>>>complained about some xml file while deploying the application:
>>>>>
>>>>> org.xml.sax.SAXParseException: Illegal character
>>>>>
>>>>>
>>>>>
>>>>>
>>>>">" (>) at
>>>>
>>>>
>>>>
>>>>
>>>>>end
>>>>>of XML Declaration.
>>>>>
>>>>> Anyway, I'll try to take a look at the sources... can
>>>>>
>>>>>
>>>>>
>>>>>
>>>>you point me
>>>>
>>>>
>>>>
>>>>
>>>>>to the place where this is done?
>>>>>
>>>>> Thanks a lot, regards
>>>>> Jose
>>>>>
>>>>>Bill Lear wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>On Wednesday, September 3, 2003 at 00:15:23 (+0200) Jose Gonzalez
>>>>>>Gomez writes:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> I've searched through the list archives for this, but
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>I haven't
>>>>
>>>>
>>>>
>>>>
>>>>>>>been
>>>>>>>able to find a definitive answer. The problem is: we'd
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>like to use
>>>>
>>>>
>>>>
>>>>
>>>>>>>Tapestry to build the web layer of an application, but
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>this application
>>>>
>>>>
>>>>
>>>>
>>>>>>>makes intensive use of the J2EE declarative security in
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>its EJB layer,
>>>>
>>>>
>>>>
>>>>
>>>>>>>so we must authenticate the user using the J2EE mechanism
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>(in this case,
>>>>
>>>>
>>>>
>>>>
>>>>>>>form based authentication) to get this security
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>information propagated
>>>>
>>>>
>>>>
>>>>
>>>>>>>to the EJB layer automatically. We'd also like to have
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>some Tapestry
>>>>
>>>>
>>>>
>>>>
>>>>>>>pages protected so only users with some given role are
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>able to access them.
>>>>
>>>>
>>>>
>>>>
>>>>>>>The question is: what's the recommended approach to
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>solve this, if
>>>>
>>>>
>>>>
>>>>
>>>>>>>there is any? Any help would be greatly appreciated, as
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>right now this
>>>>
>>>>
>>>>
>>>>
>>>>>>>is the only important reason that prevents us from
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>choosing Tapestry
>>>>
>>>>
>>>>
>>>>
>>>>>>>instead of Struts.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>Have you taken a look at the Vlib example?
>>>>>>
>>>>>>
>>>>>>Bill
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>-----------------------------------------------------------
>>>>>
>>>>>
>>----------
>>
>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>To unsubscribe, e-mail:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>tapestry-user-unsubscribe@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>>>For additional commands, e-mail:
>>>>>>tapestry-user-help@jakarta.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>------------------------------------------------------------
>>>>
>>>>
>>---------
>>
>>
>>>>
>>>>
>>>>
>>>>
>>>>>To unsubscribe, e-mail:
>>>>>
>>>>>
>>tapestry-user-unsubscribe@jakarta.apache.org
>>
>>
>>>>>For additional commands, e-mail:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>tapestry-user-help@jakarta.apache.org
>>>>--
>>>>Dan Wells <da...@byu.edu>
>>>>
>>>>
>>>>------------------------------------------------------------
>>>>
>>>>
>>---------
>>
>>
>>>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail:
>>>>
>>>>
>>tapestry-user-help@jakarta.apache.org
>>
>>
>>>>
>>>>
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail:
>>>
>>>
>>tapestry-user-help@jakarta.apache.org
>>
>>
>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: J2EE authentication and authorization
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
I've never been a fan of J2EE security, since it is static and role based. In the applications I've
worked on, the same user will have different roles in different contexts. In addition, the J2EE
security model doesn't support the ability to query what operations are allowed within the user's
current role ... because a real web application will simply not present (or, alternately, visibly
disable) fixtures for operations that are not available; that just isn't possible unless you can ask
the security system what the user can do ... or you have to duplicate security data in the
presentation layer.
Anyway, J2EE security is often based on URL patterns, which is also not a good fit for Tapestry,
since Tapestry URLs are pretty much fixed ("/vlib/app", with different query parameters).
Every application I've worked on has used application level security for these reasons; therefore,
I've never considered it a priority for Tapestry.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
> -----Original Message-----
> From: Jose Gonzalez Gomez [mailto:jgonzalez@opentechnet.com]
> Sent: Wednesday, September 03, 2003 11:47 AM
> To: Tapestry users
> Subject: Re: J2EE authentication and authorization
>
>
>
> Howard,
>
> Any thoughts from you about the J2EE web security
> integration would
> be greatly appreciated.
>
> Regards
>
> Howard M. Lewis Ship wrote:
>
> >This is another reason that we should produce a beta-3 ... it's
> >overdue, given that some of the examples in beta-2 don't work.
> >
> >--
> >Howard M. Lewis Ship
> >Creator, Tapestry: Java Web Components
> >http://jakarta.apache.org/tapestry
> >http://jakarta.apache.org/commons/sandbox/hivemind/
> >http://javatapestry.blogspot.com
> >
> >
> >
> >>-----Original Message-----
> >>From: dvw3@email.byu.edu [mailto:dvw3@email.byu.edu] On
> >>Behalf Of Dan Wells
> >>Sent: Wednesday, September 03, 2003 10:45 AM
> >>To: Tapestry users
> >>Subject: Re: J2EE authentication and authorization
> >>
> >>
> >>I ran into this SAXParseException too. Please see
> >>
> >>http://article.gmane.org/gmane.comp.java.tapestry.user/2628/ma
> >>tch=dan+wells+jboss
> >>
> >>The important part is this:
> >>
> >>"To fix the problem, I had to edit the jbosscmp-jdbc.xml and
> >>the jboss.xml files for the vlibbeans.jar. They did not have
> >>the closing '?' symbol of the <?xml version=.... element on
> >>the first line."
> >>
> >>I hope that helps.
> >>
> >>On Tue, 2003-09-02 at 16:28, Jose Gonzalez Gomez wrote:
> >>
> >>
> >>> Bill,
> >>>
> >>> I haven't... I tried to install it in JBoss 3.0.6, but crimson
> >>>complained about some xml file while deploying the application:
> >>>
> >>> org.xml.sax.SAXParseException: Illegal character
> >>>
> >>>
> >>">" (>) at
> >>
> >>
> >>>end
> >>>of XML Declaration.
> >>>
> >>> Anyway, I'll try to take a look at the sources... can
> >>>
> >>>
> >>you point me
> >>
> >>
> >>>to the place where this is done?
> >>>
> >>> Thanks a lot, regards
> >>> Jose
> >>>
> >>>Bill Lear wrote:
> >>>
> >>>
> >>>
> >>>>On Wednesday, September 3, 2003 at 00:15:23 (+0200) Jose Gonzalez
> >>>>Gomez writes:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> I've searched through the list archives for this, but
> >>>>>
> >>>>>
> >>I haven't
> >>
> >>
> >>>>>been
> >>>>>able to find a definitive answer. The problem is: we'd
> >>>>>
> >>>>>
> >>like to use
> >>
> >>
> >>>>>Tapestry to build the web layer of an application, but
> >>>>>
> >>>>>
> >>this application
> >>
> >>
> >>>>>makes intensive use of the J2EE declarative security in
> >>>>>
> >>>>>
> >>its EJB layer,
> >>
> >>
> >>>>>so we must authenticate the user using the J2EE mechanism
> >>>>>
> >>>>>
> >>(in this case,
> >>
> >>
> >>>>>form based authentication) to get this security
> >>>>>
> >>>>>
> >>information propagated
> >>
> >>
> >>>>>to the EJB layer automatically. We'd also like to have
> >>>>>
> >>>>>
> >>some Tapestry
> >>
> >>
> >>>>>pages protected so only users with some given role are
> >>>>>
> >>>>>
> >>able to access them.
> >>
> >>
> >>>>> The question is: what's the recommended approach to
> >>>>>
> >>>>>
> >>solve this, if
> >>
> >>
> >>>>>there is any? Any help would be greatly appreciated, as
> >>>>>
> >>>>>
> >>right now this
> >>
> >>
> >>>>>is the only important reason that prevents us from
> >>>>>
> >>>>>
> >>choosing Tapestry
> >>
> >>
> >>>>>instead of Struts.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>Have you taken a look at the Vlib example?
> >>>>
> >>>>
> >>>>Bill
> >>>>
> >>>>
> >>>>
> >>>-----------------------------------------------------------
> ----------
> >>>
> >>>
> >>>>To unsubscribe, e-mail:
> >>>>
> >>>>
> >>tapestry-user-unsubscribe@jakarta.apache.org
> >>
> >>
> >>>>For additional commands, e-mail:
> >>>>tapestry-user-help@jakarta.apache.org
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>------------------------------------------------------------
> ---------
> >>
> >>
> >>>To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail:
> >>>
> >>>
> >>tapestry-user-help@jakarta.apache.org
> >>--
> >>Dan Wells <da...@byu.edu>
> >>
> >>
> >>------------------------------------------------------------
> ---------
> >>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
> >>
> >>
> >>
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: J2EE authentication and authorization
Posted by Jose Gonzalez Gomez <jg...@opentechnet.com>.
Howard,
Any thoughts from you about the J2EE web security integration would
be greatly appreciated.
Regards
Howard M. Lewis Ship wrote:
>This is another reason that we should produce a beta-3 ... it's overdue, given that some of the
>examples in beta-2 don't work.
>
>--
>Howard M. Lewis Ship
>Creator, Tapestry: Java Web Components
>http://jakarta.apache.org/tapestry
>http://jakarta.apache.org/commons/sandbox/hivemind/
>http://javatapestry.blogspot.com
>
>
>
>>-----Original Message-----
>>From: dvw3@email.byu.edu [mailto:dvw3@email.byu.edu] On
>>Behalf Of Dan Wells
>>Sent: Wednesday, September 03, 2003 10:45 AM
>>To: Tapestry users
>>Subject: Re: J2EE authentication and authorization
>>
>>
>>I ran into this SAXParseException too. Please see
>>
>>http://article.gmane.org/gmane.comp.java.tapestry.user/2628/ma
>>tch=dan+wells+jboss
>>
>>The important part is this:
>>
>>"To fix the problem, I had to edit the jbosscmp-jdbc.xml and
>>the jboss.xml files for the vlibbeans.jar. They did not have
>>the closing '?' symbol of the <?xml version=.... element on
>>the first line."
>>
>>I hope that helps.
>>
>>On Tue, 2003-09-02 at 16:28, Jose Gonzalez Gomez wrote:
>>
>>
>>> Bill,
>>>
>>> I haven't... I tried to install it in JBoss 3.0.6, but crimson
>>>complained about some xml file while deploying the application:
>>>
>>> org.xml.sax.SAXParseException: Illegal character
>>>
>>>
>>">" (>) at
>>
>>
>>>end
>>>of XML Declaration.
>>>
>>> Anyway, I'll try to take a look at the sources... can
>>>
>>>
>>you point me
>>
>>
>>>to the place where this is done?
>>>
>>> Thanks a lot, regards
>>> Jose
>>>
>>>Bill Lear wrote:
>>>
>>>
>>>
>>>>On Wednesday, September 3, 2003 at 00:15:23 (+0200) Jose Gonzalez
>>>>Gomez writes:
>>>>
>>>>
>>>>
>>>>
>>>>> I've searched through the list archives for this, but
>>>>>
>>>>>
>>I haven't
>>
>>
>>>>>been
>>>>>able to find a definitive answer. The problem is: we'd
>>>>>
>>>>>
>>like to use
>>
>>
>>>>>Tapestry to build the web layer of an application, but
>>>>>
>>>>>
>>this application
>>
>>
>>>>>makes intensive use of the J2EE declarative security in
>>>>>
>>>>>
>>its EJB layer,
>>
>>
>>>>>so we must authenticate the user using the J2EE mechanism
>>>>>
>>>>>
>>(in this case,
>>
>>
>>>>>form based authentication) to get this security
>>>>>
>>>>>
>>information propagated
>>
>>
>>>>>to the EJB layer automatically. We'd also like to have
>>>>>
>>>>>
>>some Tapestry
>>
>>
>>>>>pages protected so only users with some given role are
>>>>>
>>>>>
>>able to access them.
>>
>>
>>>>> The question is: what's the recommended approach to
>>>>>
>>>>>
>>solve this, if
>>
>>
>>>>>there is any? Any help would be greatly appreciated, as
>>>>>
>>>>>
>>right now this
>>
>>
>>>>>is the only important reason that prevents us from
>>>>>
>>>>>
>>choosing Tapestry
>>
>>
>>>>>instead of Struts.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Have you taken a look at the Vlib example?
>>>>
>>>>
>>>>Bill
>>>>
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>
>>>
>>>>To unsubscribe, e-mail:
>>>>
>>>>
>>tapestry-user-unsubscribe@jakarta.apache.org
>>
>>
>>>>For additional commands, e-mail:
>>>>tapestry-user-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>
>>
>>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail:
>>>
>>>
>>tapestry-user-help@jakarta.apache.org
>>--
>>Dan Wells <da...@byu.edu>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: J2EE authentication and authorization
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
This is another reason that we should produce a beta-3 ... it's overdue, given that some of the
examples in beta-2 don't work.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
> -----Original Message-----
> From: dvw3@email.byu.edu [mailto:dvw3@email.byu.edu] On
> Behalf Of Dan Wells
> Sent: Wednesday, September 03, 2003 10:45 AM
> To: Tapestry users
> Subject: Re: J2EE authentication and authorization
>
>
> I ran into this SAXParseException too. Please see
>
> http://article.gmane.org/gmane.comp.java.tapestry.user/2628/ma
> tch=dan+wells+jboss
>
> The important part is this:
>
> "To fix the problem, I had to edit the jbosscmp-jdbc.xml and
> the jboss.xml files for the vlibbeans.jar. They did not have
> the closing '?' symbol of the <?xml version=.... element on
> the first line."
>
> I hope that helps.
>
> On Tue, 2003-09-02 at 16:28, Jose Gonzalez Gomez wrote:
> > Bill,
> >
> > I haven't... I tried to install it in JBoss 3.0.6, but crimson
> > complained about some xml file while deploying the application:
> >
> > org.xml.sax.SAXParseException: Illegal character
> ">" (>) at
> > end
> > of XML Declaration.
> >
> > Anyway, I'll try to take a look at the sources... can
> you point me
> > to the place where this is done?
> >
> > Thanks a lot, regards
> > Jose
> >
> > Bill Lear wrote:
> >
> > >On Wednesday, September 3, 2003 at 00:15:23 (+0200) Jose Gonzalez
> > >Gomez writes:
> > >
> > >
> > >> I've searched through the list archives for this, but
> I haven't
> > >>been
> > >>able to find a definitive answer. The problem is: we'd
> like to use
> > >>Tapestry to build the web layer of an application, but
> this application
> > >>makes intensive use of the J2EE declarative security in
> its EJB layer,
> > >>so we must authenticate the user using the J2EE mechanism
> (in this case,
> > >>form based authentication) to get this security
> information propagated
> > >>to the EJB layer automatically. We'd also like to have
> some Tapestry
> > >>pages protected so only users with some given role are
> able to access them.
> > >>
> > >> The question is: what's the recommended approach to
> solve this, if
> > >>there is any? Any help would be greatly appreciated, as
> right now this
> > >>is the only important reason that prevents us from
> choosing Tapestry
> > >>instead of Struts.
> > >>
> > >>
> > >
> > >Have you taken a look at the Vlib example?
> > >
> > >
> > >Bill
> > >
> >
> >---------------------------------------------------------------------
> > >To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> > >For additional commands, e-mail:
> > >tapestry-user-help@jakarta.apache.org
> > >
> > >
> > >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
> --
> Dan Wells <da...@byu.edu>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: J2EE authentication and authorization
Posted by Dan Wells <da...@byu.edu>.
I ran into this SAXParseException too. Please see
http://article.gmane.org/gmane.comp.java.tapestry.user/2628/match=dan+wells+jboss
The important part is this:
"To fix the problem, I had to edit the jbosscmp-jdbc.xml and
the jboss.xml files for the vlibbeans.jar. They did not have
the closing '?' symbol of the <?xml version=.... element on
the first line."
I hope that helps.
On Tue, 2003-09-02 at 16:28, Jose Gonzalez Gomez wrote:
> Bill,
>
> I haven't... I tried to install it in JBoss 3.0.6, but crimson
> complained about some xml file while deploying the application:
>
> org.xml.sax.SAXParseException: Illegal character ">" (>) at end
> of XML Declaration.
>
> Anyway, I'll try to take a look at the sources... can you point me
> to the place where this is done?
>
> Thanks a lot, regards
> Jose
>
> Bill Lear wrote:
>
> >On Wednesday, September 3, 2003 at 00:15:23 (+0200) Jose Gonzalez Gomez writes:
> >
> >
> >> I've searched through the list archives for this, but I haven't been
> >>able to find a definitive answer. The problem is: we'd like to use
> >>Tapestry to build the web layer of an application, but this application
> >>makes intensive use of the J2EE declarative security in its EJB layer,
> >>so we must authenticate the user using the J2EE mechanism (in this case,
> >>form based authentication) to get this security information propagated
> >>to the EJB layer automatically. We'd also like to have some Tapestry
> >>pages protected so only users with some given role are able to access them.
> >>
> >> The question is: what's the recommended approach to solve this, if
> >>there is any? Any help would be greatly appreciated, as right now this
> >>is the only important reason that prevents us from choosing Tapestry
> >>instead of Struts.
> >>
> >>
> >
> >Have you taken a look at the Vlib example?
> >
> >
> >Bill
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
--
Dan Wells <da...@byu.edu>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: J2EE authentication and authorization
Posted by Jose Gonzalez Gomez <jg...@opentechnet.com>.
Bill,
I haven't... I tried to install it in JBoss 3.0.6, but crimson
complained about some xml file while deploying the application:
org.xml.sax.SAXParseException: Illegal character ">" (>) at end
of XML Declaration.
Anyway, I'll try to take a look at the sources... can you point me
to the place where this is done?
Thanks a lot, regards
Jose
Bill Lear wrote:
>On Wednesday, September 3, 2003 at 00:15:23 (+0200) Jose Gonzalez Gomez writes:
>
>
>> I've searched through the list archives for this, but I haven't been
>>able to find a definitive answer. The problem is: we'd like to use
>>Tapestry to build the web layer of an application, but this application
>>makes intensive use of the J2EE declarative security in its EJB layer,
>>so we must authenticate the user using the J2EE mechanism (in this case,
>>form based authentication) to get this security information propagated
>>to the EJB layer automatically. We'd also like to have some Tapestry
>>pages protected so only users with some given role are able to access them.
>>
>> The question is: what's the recommended approach to solve this, if
>>there is any? Any help would be greatly appreciated, as right now this
>>is the only important reason that prevents us from choosing Tapestry
>>instead of Struts.
>>
>>
>
>Have you taken a look at the Vlib example?
>
>
>Bill
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
Re: J2EE authentication and authorization - URLs for different entry
points
Posted by Jose Gonzalez Gomez <jg...@opentechnet.com>.
Viktor,
Just to clarify... I have an application with four roles: employee,
purchaser, approver and admin, and four URL collections catalog/*,
purchase/*, approve/* and admin/*. Employee may access catalog/*,
purchaser may access catalog/* and purchase/*, approver may access
catalog/* and approve/* and admin may access all of them.
Should I add four different mappings to the same servlet, or should
I define four tapestry servlets, each with its own application
definition? And what about unauthenticated access? If you take the first
approach, you'll have four different URLs pointing to the same page (am
I missing anything here?); if you take the second approach (if this is
possible), how do you link pages in different applications?
About the validation and redirection part, I think this is a common
requirement for a lot of applications, and maybe this could get to the
framework (you know, some way to describe security in terms of roles,
and let the framework take care of it). What do you think about this?
This takes me to another question... If I have understood well
through my readings, in a Tapestry application there are no known URLs,
as the framework takes care of generating them, and that's completely
transparent for the developer. So you only know one URL in advance: that
of the home page of the application. Am I right? So how do you provide
different access points to your application? Let's say I want an entry
point for the catalog part and an entry point to the admin part... the
only think that I can think of to do this is using an admin page,
provide a DirectLink to this page from the home page, and them provide
that URL as the link to enter the admin area. Is there any way to know
that URL in advance?
Thanks a lot for your help, and please, forgive me if my lack of
knowledge about Tapestry makes me ask anything stupid.
Regards
Jose
Viktor Szathmary wrote:
>hi,
>
>On Tue, 2003-09-02 at 17:50, Jose Gonzalez Gomez wrote:
>
>
>> Is there any way to integrate this kind of behavior with J2EE web
>>security?
>>
>>
>
>i've added some info on this to the tapestry wiki (btw, should we still
>be using the one at sf.net, or migrate the content to the apache wiki?)
>
>http://tapestry.sourceforge.net/wiki/index.php/TapestryFAQ
>
>regards,
> viktor
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: J2EE authentication and authorization
Posted by Viktor Szathmary <ph...@imapmail.org>.
hi,
On Tue, 2003-09-02 at 17:50, Jose Gonzalez Gomez wrote:
> Is there any way to integrate this kind of behavior with J2EE web
> security?
i've added some info on this to the tapestry wiki (btw, should we still
be using the one at sf.net, or migrate the content to the apache wiki?)
http://tapestry.sourceforge.net/wiki/index.php/TapestryFAQ
regards,
viktor
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: J2EE authentication and authorization
Posted by Jose Gonzalez Gomez <jg...@opentechnet.com>.
After a quick look at the VLib sources and some pages in the wiki it
seems that the VLib application uses a custom login page, reached after
a redirection fired in the validate method of IPage. Then the
application shows the original page using ICallback. Am I right?
Is there any way to integrate this kind of behavior with J2EE web
security?
Regards
Jose
Bill Lear wrote:
>On Wednesday, September 3, 2003 at 00:15:23 (+0200) Jose Gonzalez Gomez writes:
>
>
>> I've searched through the list archives for this, but I haven't been
>>able to find a definitive answer. The problem is: we'd like to use
>>Tapestry to build the web layer of an application, but this application
>>makes intensive use of the J2EE declarative security in its EJB layer,
>>so we must authenticate the user using the J2EE mechanism (in this case,
>>form based authentication) to get this security information propagated
>>to the EJB layer automatically. We'd also like to have some Tapestry
>>pages protected so only users with some given role are able to access them.
>>
>> The question is: what's the recommended approach to solve this, if
>>there is any? Any help would be greatly appreciated, as right now this
>>is the only important reason that prevents us from choosing Tapestry
>>instead of Struts.
>>
>>
>
>Have you taken a look at the Vlib example?
>
>
>Bill
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
Re: J2EE authentication and authorization
Posted by Bill Lear <ra...@zopyra.com>.
On Wednesday, September 3, 2003 at 00:15:23 (+0200) Jose Gonzalez Gomez writes:
>
> I've searched through the list archives for this, but I haven't been
>able to find a definitive answer. The problem is: we'd like to use
>Tapestry to build the web layer of an application, but this application
>makes intensive use of the J2EE declarative security in its EJB layer,
>so we must authenticate the user using the J2EE mechanism (in this case,
>form based authentication) to get this security information propagated
>to the EJB layer automatically. We'd also like to have some Tapestry
>pages protected so only users with some given role are able to access them.
>
> The question is: what's the recommended approach to solve this, if
>there is any? Any help would be greatly appreciated, as right now this
>is the only important reason that prevents us from choosing Tapestry
>instead of Struts.
Have you taken a look at the Vlib example?
Bill