You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by KhoiVu Nguyen <kh...@gmail.com> on 2005/02/11 23:40:21 UTC
j_security_check
I need help on how to use J2EE security declarative works with
Tapestry. I read Tapestry FAQ on 'How do I integrate a Tapestry
application with J2EE declarative security/JAAS' but I still cannot
make it to work.
Can someone explain again on how to make this j_security_check work
with Tapestry again. If someone has a sample that I can learn from
that would be great. Thank you for any helps.
Sincerely,
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: j_security_check
Posted by KhoiVu Nguyen <kh...@gmail.com>.
Michael,
I have to say thank you for your advice though. Let me go back and
read Howards book on the security and come back with more questions.
Khoivu
On Sat, 12 Feb 2005 16:43:30 +0100, Michael Echerer <me...@tngtech.com> wrote:
>
>
> KhoiVu Nguyen wrote:
> > I need help on how to use J2EE security declarative works with
> > Tapestry. I read Tapestry FAQ on 'How do I integrate a Tapestry
> > application with J2EE declarative security/JAAS' but I still cannot
> > make it to work.
> >
> > Can someone explain again on how to make this j_security_check work
> > with Tapestry again. If someone has a sample that I can learn from
> > that would be great. Thank you for any helps.
> Do yourself a favour and don't use declarative security for anything
> more advanced than automatically switching from http to https or
> protecting some subfolders. Typically this security mechanism doesn't
> work well for complex things like roles with rights, e.g. Tomcat
> requires a specific DB table format if you use a JDBCRealm which doesn't
> need to be exactly what "you" want your users table look like.
>
> Moreover the j_security_check requires the username and password form
> fields to be named j_username resp. j_password.
> On older Tomcats I had some trouble with pressing the browsers back
> button and submitting credientials twice with this declarative
> security... etc. etc. etc.
> These form names btw cannot be guaranteed so easily with Tapestry that
> tends to generate the form names automatically if not forced otherwise.
>
> To sum it up, better stick to Tapestry ways like secured pages that
> automatically switch back (using callbacks) to the page you left before
> showing the login page. See Howards book for more details or do some
> other custom security. You'll be much better of with this.
>
> Don't get me wrong... declarative security is the best you can do, if
> you need to guarantee that a certain app (or part) requires to run with
> https only, or you need a quick way to do Apache-like .htaccess stuff
> with Tomcat etc. But for more... No thanks...
>
> Cheers,
> Michael
>
> >
> > Sincerely,
> >
> > ---------------------------------------------------------------------
> > 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: j_security_check
Posted by Vince Marco <vm...@mac.com>.
Not at all. Use what works.
> I this case I've had to write my own realm adapters to resolve the
> impedance among formats. It worked well before....Is there a reason
> not to do this?
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
what is the usage of IPrimaryKeyConvertor
Posted by li...@wachovia.com.
Some tapestry user said, IprimaryKeyConvertor is for:
----
An interface defining how the items iterated upon by this component will
be stored in the form as Hidden values. This interface allows only the
primary key of the items to be stored, rather than the whole item.
---
I think getPrimaryKey(objValue) is enough to achieve that purpose, why
need getValue(Object objPrimaryKey) ?
I think getValue() should enable me to get the object that is correspond
to a row in a table directly without having to go through reconstructing
the object using primary key, but I can't find such sample or I completely
misunderstood its usage, please help!
Re: j_security_check
Posted by Daniel Honig <da...@gmail.com>.
I this case I've had to write my own realm adapters to resolve the
impedance among formats. It worked well before....Is there a reason not
to do this?
Vince Marco wrote:
>
>> Do yourself a favour and don't use declarative security for anything
>> more advanced than automatically switching from http to https or
>> protecting some subfolders. Typically this security mechanism doesn't
>> work well for complex things like roles with rights, e.g. Tomcat
>> requires a specific DB table format if you use a JDBCRealm which
>> doesn't need to be exactly what "you" want your users table look like.
>>
>
> I've found it useful to create a DB view to adapt my tables to
> specific formats required by JDBC based login modules or realms.
> Since authentication is lookup only, views work great if your DB has
> them.
>
> Vince
>
>
> ---------------------------------------------------------------------
> 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: j_security_check
Posted by Vince Marco <vm...@mac.com>.
> Do yourself a favour and don't use declarative security for anything
> more advanced than automatically switching from http to https or
> protecting some subfolders. Typically this security mechanism doesn't
> work well for complex things like roles with rights, e.g. Tomcat
> requires a specific DB table format if you use a JDBCRealm which
> doesn't need to be exactly what "you" want your users table look like.
>
I've found it useful to create a DB view to adapt my tables to specific
formats required by JDBC based login modules or realms. Since
authentication is lookup only, views work great if your DB has them.
Vince
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: j_security_check
Posted by Michael Echerer <me...@tngtech.com>.
KhoiVu Nguyen wrote:
> I need help on how to use J2EE security declarative works with
> Tapestry. I read Tapestry FAQ on 'How do I integrate a Tapestry
> application with J2EE declarative security/JAAS' but I still cannot
> make it to work.
>
> Can someone explain again on how to make this j_security_check work
> with Tapestry again. If someone has a sample that I can learn from
> that would be great. Thank you for any helps.
Do yourself a favour and don't use declarative security for anything
more advanced than automatically switching from http to https or
protecting some subfolders. Typically this security mechanism doesn't
work well for complex things like roles with rights, e.g. Tomcat
requires a specific DB table format if you use a JDBCRealm which doesn't
need to be exactly what "you" want your users table look like.
Moreover the j_security_check requires the username and password form
fields to be named j_username resp. j_password.
On older Tomcats I had some trouble with pressing the browsers back
button and submitting credientials twice with this declarative
security... etc. etc. etc.
These form names btw cannot be guaranteed so easily with Tapestry that
tends to generate the form names automatically if not forced otherwise.
To sum it up, better stick to Tapestry ways like secured pages that
automatically switch back (using callbacks) to the page you left before
showing the login page. See Howards book for more details or do some
other custom security. You'll be much better of with this.
Don't get me wrong... declarative security is the best you can do, if
you need to guarantee that a certain app (or part) requires to run with
https only, or you need a quick way to do Apache-like .htaccess stuff
with Tomcat etc. But for more... No thanks...
Cheers,
Michael
>
> Sincerely,
>
> ---------------------------------------------------------------------
> 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