Trails 1.2 & OGNL issues

[Alejandro Scandroli]

Hi All

I've been testing Trails 1.2 for a while (over two months) now, and
OGNL is giving me a huge headache.
Every thing was fine while the application was just Trails without
customizations, but when I started to grow the application, when I
stared to mix Trails pages and components with plain Tapestry pages, I
got an avalanche of OGNL exceptions.

Examples:
1) my domain model has two subsets, the core business domain model and
the identity management model. The identity management model is shared
by several application so I can't change its code.
I wanted the default page navigation to be list -> view -> edit, so I
added this simple @Block to my DefaultList page:

          <div jwcid="idColumnValue@Block">
                  <a jwcid="viewLink@trails:ViewLink" model="ognl:object"
href="#"><span jwcid="@Insert" value="ognl:object.id"/></a>
          </div>

As simple as it looks this code fails throwing a beautiful
ClassCastException if all the entity's IDs aren't of the same type.

2)

Let's say you want to save some typing and you add a nice default
value to your component parameters, like:

        @Parameter(required = false, defaultValue = "page.classDescriptor",
cache = true)
        public abstract IClassDescriptor getClassDescriptor();

This code will throw another ClassCastException if all the pages from
where it is been used do not share a common ancestor with the
getClassDescriptor method.

3)
The same thing happens for this code:

        @Parameter(defaultValue = "container.model")
        public abstract Object getModel();

This code was meant to be used indifferently from a Page or from a
Component, but it fails if the components and pages do not share a
common ancestor containing the getModel method. This means that
components like the PropertyEditor can't be used from inside another
component without explicitly setting all its parameters.


Although there are workarounds for all of them and they seem like not
so big a deal, they are huge when you depend on Trails development
speed and you have to spent most of your time working around these
issues.

On this particular project we are planning to move to T5 asap, but I
wonder what to do with the Trails 1.2 release.

What should we do?

We can't revert back to OGNL 2.6.x.
We can't use tapestry-prop.
We could remove all the "defaultValue"s and we could declare
interfaces for every known property (eg: classDescriptor,
propertyDescriptor, model, modelNew, blockFinder) but that's way too
verbose.
We could disable caching (org.apache.tapestry.disable-caching=true)
but that will not perform well at all.
We could wait until OGNL enables a "don't ever compile" option.
We could release 1.2 anyway

I'm open ears. What do you think?

BTW, here is a old and long thread about this ognl feature:
http://www.mail-archive.com/users@.../msg15191.html


Saludos.
Alejandro.


--
Alejandro Scandroli - http://weblog.amneris.es/
Amneris: We build process-driven web applications.
http://www.amneris.es

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Kalle Korhonen-2]

On Mon, May 5, 2008 at 3:22 PM, Alejandro Scandroli <alejandroscandroli@...> wrote:

I've been testing Trails 1.2 for a while (over two months) now, and
OGNL is giving me a huge headache.
Although there are workarounds for all of them and they seem like not
so big a deal, they are huge when you depend on Trails development
speed and you have to spent most of your time working around these
issues.
On this particular project we are planning to move to T5 asap, but I
wonder what to do with the Trails 1.2 release.
What should we do?

We can't revert back to OGNL 2.6.x.
We can't use tapestry-prop.
We could remove all the "defaultValue"s and we could declare
interfaces for every known property (eg: classDescriptor,
propertyDescriptor, model, modelNew, blockFinder) but that's way too
verbose.
We could disable caching (org.apache.tapestry.disable-caching=true)
but that will not perform well at all.
We could wait until OGNL enables a "don't ever compile" option.
We could release 1.2 anyway

I'm using 1.2-SNAPSHOTs. I think we should release 1.2 anyway, and just properly document (and link to OGNL documentation that explains) compiled expressions and why you can and should always use #this when a compiled expression doesn't work. I know that compiled OGNL and using mixed types doesn't work and it's given me headaches as well, but I'm not willing to let go of the improved performance that compiled OGNL brings for the majority of the use cases. Disabling caching is not an option for other than development; when disabled, it'll pollute permgen space over time no matter how big it is.

Kalle

[nhhockeyplayer]

Sounds like modeling and interfacing lapses with the ID's...
 
regardless
 
Not all folks will be able to juggle and articulate documented issues with OGNL and then be pressed to resolve each individual case given their situation. Re-write feels kind like a howard re-write. Painful to what lies ahead. So I think trails should try to accomodate the best case that supports a runnable 1.2 framework.
 
I will be happy to maintain 1.2 (at my own pace) while you guys go off and re-do 1.3. Something to think about.
 
I recently logged an ognl issue and it took out the whole app... just from a complicated expression... no exception thrown either. I interpretted it as internal corruption... as event handlers were not even being invoked and the app ran until ognl completely gave out.

A list of best-careful-practices are definitely in order with other workarounds.
 
Caching disabled is unusable my version with caching on running pojo gallery is slow enough.

Best regards
Ken in nashua

---

Date: Mon, 5 May 2008 16:26:18 -0700
From: kalle.o.korhonen@...
To: users@...
CC: spedra@...
Subject: Re: [trails-users] Trails 1.2 & OGNL issues

On Mon, May 5, 2008 at 3:22 PM, Alejandro Scandroli <alejandroscandroli@...> wrote:

I've been testing Trails 1.2 for a while (over two months) now, and
OGNL is giving me a huge headache.
Although there are workarounds for all of them and they seem like not
so big a deal, they are huge when you depend on Trails development
speed and you have to spent most of your time working around these
issues.
On this particular project we are planning to move to T5 asap, but I
wonder what to do with the Trails 1.2 release.
What should we do?

We can't revert back to OGNL 2.6.x.
We can't use tapestry-prop.
We could remove all the "defaultValue"s and we could declare
interfaces for every known property (eg: classDescriptor,
propertyDescriptor, model, modelNew, blockFinder) but that's way too
verbose.
We could disable caching (org.apache.tapestry.disable-caching=true)
but that will not perform well at all.
We could wait until OGNL enables a "don't ever compile" option.
We could release 1.2 anyway

I'm using 1.2-SNAPSHOTs. I think we should release 1.2 anyway, and just properly document (and link to OGNL documentation that explains) compiled expressions and why you can and should always use #this when a compiled expression doesn't work. I know that compiled OGNL and using mixed types doesn't work and it's given me headaches as well, but I'm not willing to let go of the improved performance that compiled OGNL brings for the majority of the use cases. Disabling caching is not an option for other than development; when disabled, it'll pollute permgen space over time no matter how big it is.

Kalle

---

Windows Live SkyDrive lets you share files with faraway friends. Start sharing.

[Alejandro Scandroli]

Ok, fair enough.
It looks like I didn't fully get what #this was for, I thought it was
just a temporary quick workaround. I will explore it a little bit
more.

Thanks.
Alejandro.


On Tue, May 6, 2008 at 1:26 AM, Kalle Korhonen
<kalle.o.korhonen@...> wrote:

> On Mon, May 5, 2008 at 3:22 PM, Alejandro Scandroli
> <alejandroscandroli@...> wrote:
>
> >
> > I've been testing Trails 1.2 for a while (over two months) now, and
> > OGNL is giving me a huge headache.
> >
> > Although there are workarounds for all of them and they seem like not
> > so big a deal, they are huge when you depend on Trails development
> > speed and you have to spent most of your time working around these
> > issues.
> > On this particular project we are planning to move to T5 asap, but I
> > wonder what to do with the Trails 1.2 release.
> > What should we do?
> >
> > We can't revert back to OGNL 2.6.x.
> > We can't use tapestry-prop.
> > We could remove all the "defaultValue"s and we could declare
> > interfaces for every known property (eg: classDescriptor,
> > propertyDescriptor, model, modelNew, blockFinder) but that's way too
> > verbose.
> > We could disable caching (org.apache.tapestry.disable-caching=true)
> > but that will not perform well at all.
> > We could wait until OGNL enables a "don't ever compile" option.
> > We could release 1.2 anyway
> >
> >
>
> I'm using 1.2-SNAPSHOTs. I think we should release 1.2 anyway, and just
> properly document (and link to OGNL documentation that explains) compiled
> expressions and why you can and should always use #this when a compiled
> expression doesn't work. I know that compiled OGNL and using mixed types
> doesn't work and it's given me headaches as well, but I'm not willing to let
> go of the improved performance that compiled OGNL brings for the majority of
> the use cases. Disabling caching is not an option for other than
> development; when disabled, it'll pollute permgen space over time no matter
> how big it is.
>
> Kalle
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Toby78]

There are some issues about Trails Security that might maybe
be configurable - I hope they are.

By default, Trails Security is quite unsecure:

1. Username/password on the login page are passed via GET in the URL !!!
2. If Cookies are disabled, Session IDs are used - that are easily hijackable....

Is there a workaround?

Thanks!


Tobias

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Kalle Korhonen-2]

Use POST to send the login form via https. These certainly are easily configurable but not necessarily the best defaults when you first start developing a web application - which is why Trails and web app frameworks typically have the simplest options for demonstration purposes.

Kalle

On Mon, May 26, 2008 at 7:41 AM, Tobias Marx <superoverdrive@...> wrote:

There are some issues about Trails Security that might maybe
be configurable - I hope they are.

By default, Trails Security is quite unsecure:

1. Username/password on the login page are passed via GET in the URL !!!
2. If Cookies are disabled, Session IDs are used - that are easily hijackable....

Is there a workaround?

Thanks!


Tobias

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[Toby78]

Yes, this is what I did now...but what about the automatic session-id fallback? Or is it possible to switch this off ?

Session IDs are bad - unless they change with every request....and/or are ip address related (but ips change, too).


-------- Original-Nachricht --------
> Datum: Mon, 26 May 2008 09:26:56 -0700
> Von: "Kalle Korhonen" <kalle.o.korhonen@...>
> An: users@...
> Betreff: Re: [trails-users] Trails Security unsecure ???

> Use POST to send the login form via https. These certainly are easily
> configurable but not necessarily the best defaults when you first start
> developing a web application - which is why Trails and web app frameworks
> typically have the simplest options for demonstration purposes.
>
> Kalle
>
>
> On Mon, May 26, 2008 at 7:41 AM, Tobias Marx <superoverdrive@...>
> wrote:
>
> > There are some issues about Trails Security that might maybe
> > be configurable - I hope they are.
> >
> > By default, Trails Security is quite unsecure:
> >
> > 1. Username/password on the login page are passed via GET in the URL !!!
> > 2. If Cookies are disabled, Session IDs are used - that are easily
> > hijackable....
> >
> > Is there a workaround?
> >
> > Thanks!
> >
> >
> > Tobias
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> >    http://xircles.codehaus.org/manage_email
> >
> >
> >

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Kalle Korhonen-2]

Obviously session ids do not change with every request; that's why they are *session* ids. The servlet spec defines cookies and url rewriting as the methods for session tracking and it doesn't declare any way to instruct the container to only use either one or the other. Containers may allow to configure it. For example, Tomcat allows you to disable cookies, but not url re-writing (http://tomcat.apache.org/tomcat-5.5-doc/config/context.html). Naturally though, you can choose to not allow sessions at all. You can disable url re-writing manually with a simple filter, but passing in the jsessionid in the request header (as in cookie) isn't considerably more secure than passing it in the url. Use https only if you want to secure all communication to your site.

Kalle

On Mon, May 26, 2008 at 10:15 AM, Tobias Marx <superoverdrive@...> wrote:

Yes, this is what I did now...but what about the automatic session-id fallback? Or is it possible to switch this off ?

Session IDs are bad - unless they change with every request....and/or are ip address related (but ips change, too).


-------- Original-Nachricht --------
> Datum: Mon, 26 May 2008 09:26:56 -0700
> Von: "Kalle Korhonen" <kalle.o.korhonen@...>
> An: users@...
> Betreff: Re: [trails-users] Trails Security unsecure ???

> Use POST to send the login form via https. These certainly are easily
> configurable but not necessarily the best defaults when you first start
> developing a web application - which is why Trails and web app frameworks
> typically have the simplest options for demonstration purposes.
>
> Kalle
>
>
> On Mon, May 26, 2008 at 7:41 AM, Tobias Marx <superoverdrive@...>
> wrote:
>
> > There are some issues about Trails Security that might maybe
> > be configurable - I hope they are.
> >
> > By default, Trails Security is quite unsecure:
> >
> > 1. Username/password on the login page are passed via GET in the URL !!!
> > 2. If Cookies are disabled, Session IDs are used - that are easily
> > hijackable....
> >
> > Is there a workaround?
> >
> > Thanks!
> >
> >
> > Tobias
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> >    http://xircles.codehaus.org/manage_email
> >
> >
> >

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[Toby78]

The problem is though, that anyone can easily hijack your session this way....you just need to visit another website and then, the URL including your session id is included in the referrer url...so in this respect all Trails security applications have a "security hole" if you dont do anything else.....

There are some frameworks that also change the session id on every request....anyway, but I still think cookies is the safest way - but there is no way to disable them in the application...you can only use jk_stripsession in Tomcat.

-------- Original-Nachricht --------
> Datum: Mon, 26 May 2008 11:56:43 -0700
> Von: "Kalle Korhonen" <kalle.o.korhonen@...>
> An: users@...
> Betreff: Re: [trails-users] Trails Security unsecure ???

> Obviously session ids do not change with every request; that's why they
> are
> *session* ids. The servlet spec defines cookies and url rewriting as the
> methods for session tracking and it doesn't declare any way to instruct
> the
> container to only use either one or the other. Containers may allow to
> configure it. For example, Tomcat allows you to disable cookies, but not
> url
> re-writing (http://tomcat.apache.org/tomcat-5.5-doc/config/context.html).
> Naturally though, you can choose to not allow sessions at all. You can
> disable url re-writing manually with a simple filter, but passing in the
> jsessionid in the request header (as in cookie) isn't considerably more
> secure than passing it in the url. Use https only if you want to secure
> all
> communication to your site.
>
> Kalle
>
>
> On Mon, May 26, 2008 at 10:15 AM, Tobias Marx <superoverdrive@...>
> wrote:
>
> > Yes, this is what I did now...but what about the automatic session-id
> > fallback? Or is it possible to switch this off ?
> >
> > Session IDs are bad - unless they change with every request....and/or
> are
> > ip address related (but ips change, too).
> >
> >
> > -------- Original-Nachricht --------
> > > Datum: Mon, 26 May 2008 09:26:56 -0700
> > > Von: "Kalle Korhonen" <kalle.o.korhonen@...>
> > > An: users@...
> > > Betreff: Re: [trails-users] Trails Security unsecure ???
> >
> > > Use POST to send the login form via https. These certainly are easily
> > > configurable but not necessarily the best defaults when you first
> start
> > > developing a web application - which is why Trails and web app
> frameworks
> > > typically have the simplest options for demonstration purposes.
> > >
> > > Kalle
> > >
> > >
> > > On Mon, May 26, 2008 at 7:41 AM, Tobias Marx <superoverdrive@...>
> > > wrote:
> > >
> > > > There are some issues about Trails Security that might maybe
> > > > be configurable - I hope they are.
> > > >
> > > > By default, Trails Security is quite unsecure:
> > > >
> > > > 1. Username/password on the login page are passed via GET in the URL
> > !!!
> > > > 2. If Cookies are disabled, Session IDs are used - that are easily
> > > > hijackable....
> > > >
> > > > Is there a workaround?
> > > >
> > > > Thanks!
> > > >
> > > >
> > > > Tobias
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe from this list, please visit:
> > > >
> > > >    http://xircles.codehaus.org/manage_email
> > > >
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> >    http://xircles.codehaus.org/manage_email
> >
> >
> >

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Kalle Korhonen-2]

On Mon, May 26, 2008 at 1:00 PM, Tobias Marx <superoverdrive@...> wrote:

The problem is though, that anyone can easily hijack your session this way....you just need to visit another website and then, the URL including your session id is included in the referrer url...so in this respect all Trails security applications have a "security hole" if you dont do anything else.....

This is not Trails-specific, it's standard servlet-based application behavior.
 

There are some frameworks that also change the session id on every request....anyway, but I still think cookies is the safest way - but there is no way to disable them in the application...you can only use jk_stripsession in Tomcat.

If you are truly worried about this, do not rely on cookies being any more secure. The headers just as easily readable as the url. As I said, you can disable url rewriting by writing a simple servlet filter.

Kalle

 

-------- Original-Nachricht --------
> Datum: Mon, 26 May 2008 11:56:43 -0700

> Von: "Kalle Korhonen" <kalle.o.korhonen@...>
> An: users@...
> Betreff: Re: [trails-users] Trails Security unsecure ???

> Obviously session ids do not change with every request; that's why they
> are
> *session* ids. The servlet spec defines cookies and url rewriting as the
> methods for session tracking and it doesn't declare any way to instruct
> the
> container to only use either one or the other. Containers may allow to
> configure it. For example, Tomcat allows you to disable cookies, but not
> url
> re-writing (http://tomcat.apache.org/tomcat-5.5-doc/config/context.html).
> Naturally though, you can choose to not allow sessions at all. You can
> disable url re-writing manually with a simple filter, but passing in the
> jsessionid in the request header (as in cookie) isn't considerably more
> secure than passing it in the url. Use https only if you want to secure
> all
> communication to your site.
>
> Kalle
>
>
> On Mon, May 26, 2008 at 10:15 AM, Tobias Marx <superoverdrive@...>
> wrote:
>
> > Yes, this is what I did now...but what about the automatic session-id
> > fallback? Or is it possible to switch this off ?
> >
> > Session IDs are bad - unless they change with every request....and/or
> are
> > ip address related (but ips change, too).
> >
> >
> > -------- Original-Nachricht --------
> > > Datum: Mon, 26 May 2008 09:26:56 -0700
> > > Von: "Kalle Korhonen" <kalle.o.korhonen@...>
> > > An: users@...
> > > Betreff: Re: [trails-users] Trails Security unsecure ???
> >
> > > Use POST to send the login form via https. These certainly are easily
> > > configurable but not necessarily the best defaults when you first
> start
> > > developing a web application - which is why Trails and web app
> frameworks
> > > typically have the simplest options for demonstration purposes.
> > >
> > > Kalle
> > >
> > >
> > > On Mon, May 26, 2008 at 7:41 AM, Tobias Marx <superoverdrive@...>
> > > wrote:
> > >
> > > > There are some issues about Trails Security that might maybe
> > > > be configurable - I hope they are.
> > > >
> > > > By default, Trails Security is quite unsecure:
> > > >
> > > > 1. Username/password on the login page are passed via GET in the URL
> > !!!
> > > > 2. If Cookies are disabled, Session IDs are used - that are easily
> > > > hijackable....
> > > >
> > > > Is there a workaround?
> > > >
> > > > Thanks!
> > > >
> > > >
> > > > Tobias
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe from this list, please visit:
> > > >
> > > >    http://xircles.codehaus.org/manage_email
> > > >
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> >    http://xircles.codehaus.org/manage_email
> >
> >
> >

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[Toby78]

Yes, they are readable - but they are not directly visible for example
in referrer urls on other websites....

So what do you do, to protect your applications? Or are you mainly doing intranet applications where those issues are not important?


-------- Original-Nachricht --------
> Datum: Mon, 26 May 2008 14:22:50 -0700
> Von: "Kalle Korhonen" <kalle.o.korhonen@...>
> An: users@...
> Betreff: Re: [trails-users] Trails Security unsecure ???

> On Mon, May 26, 2008 at 1:00 PM, Tobias Marx <superoverdrive@...>
> wrote:
>
> > The problem is though, that anyone can easily hijack your session this
> > way....you just need to visit another website and then, the URL
> including
> > your session id is included in the referrer url...so in this respect all
> > Trails security applications have a "security hole" if you dont do
> anything
> > else.....
>
>
> This is not Trails-specific, it's standard servlet-based application
> behavior.
>
>
> > There are some frameworks that also change the session id on every
> > request....anyway, but I still think cookies is the safest way - but
> there
> > is no way to disable them in the application...you can only use
> > jk_stripsession in Tomcat.
>
>
> If you are truly worried about this, do not rely on cookies being any more
> secure. The headers just as easily readable as the url. As I said, you can
> disable url rewriting by writing a simple servlet filter.
>
> Kalle
>
>
>
> > -------- Original-Nachricht --------
> > > Datum: Mon, 26 May 2008 11:56:43 -0700
> > > Von: "Kalle Korhonen" <kalle.o.korhonen@...>
> > > An: users@...
> > > Betreff: Re: [trails-users] Trails Security unsecure ???
> >
> > > Obviously session ids do not change with every request; that's why
> they
> > > are
> > > *session* ids. The servlet spec defines cookies and url rewriting as
> the
> > > methods for session tracking and it doesn't declare any way to
> instruct
> > > the
> > > container to only use either one or the other. Containers may allow to
> > > configure it. For example, Tomcat allows you to disable cookies, but
> not
> > > url
> > > re-writing
> (http://tomcat.apache.org/tomcat-5.5-doc/config/context.html
> > ).
> > > Naturally though, you can choose to not allow sessions at all. You can
> > > disable url re-writing manually with a simple filter, but passing in
> the
> > > jsessionid in the request header (as in cookie) isn't considerably
> more
> > > secure than passing it in the url. Use https only if you want to
> secure
> > > all
> > > communication to your site.
> > >
> > > Kalle
> > >
> > >
> > > On Mon, May 26, 2008 at 10:15 AM, Tobias Marx <superoverdrive@...>
> > > wrote:
> > >
> > > > Yes, this is what I did now...but what about the automatic
> session-id
> > > > fallback? Or is it possible to switch this off ?
> > > >
> > > > Session IDs are bad - unless they change with every
> request....and/or
> > > are
> > > > ip address related (but ips change, too).
> > > >
> > > >
> > > > -------- Original-Nachricht --------
> > > > > Datum: Mon, 26 May 2008 09:26:56 -0700
> > > > > Von: "Kalle Korhonen" <kalle.o.korhonen@...>
> > > > > An: users@...
> > > > > Betreff: Re: [trails-users] Trails Security unsecure ???
> > > >
> > > > > Use POST to send the login form via https. These certainly are
> easily
> > > > > configurable but not necessarily the best defaults when you first
> > > start
> > > > > developing a web application - which is why Trails and web app
> > > frameworks
> > > > > typically have the simplest options for demonstration purposes.
> > > > >
> > > > > Kalle
> > > > >
> > > > >
> > > > > On Mon, May 26, 2008 at 7:41 AM, Tobias Marx
> <superoverdrive@...>
> > > > > wrote:
> > > > >
> > > > > > There are some issues about Trails Security that might maybe
> > > > > > be configurable - I hope they are.
> > > > > >
> > > > > > By default, Trails Security is quite unsecure:
> > > > > >
> > > > > > 1. Username/password on the login page are passed via GET in the
> > URL
> > > > !!!
> > > > > > 2. If Cookies are disabled, Session IDs are used - that are
> easily
> > > > > > hijackable....
> > > > > >
> > > > > > Is there a workaround?
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > >
> > > > > > Tobias
> > > > > >
> > > > > >
> > > ---------------------------------------------------------------------
> > > > > > To unsubscribe from this list, please visit:
> > > > > >
> > > > > >    http://xircles.codehaus.org/manage_email
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe from this list, please visit:
> > > >
> > > >    http://xircles.codehaus.org/manage_email
> > > >
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> >    http://xircles.codehaus.org/manage_email
> >
> >
> >

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Kalle Korhonen-2]

On 5/26/08, Tobias Marx <superoverdrive@...> wrote:

Yes, they are readable - but they are not directly visible for example
in referrer urls on other websites....
So what do you do, to protect your applications? Or are you mainly doing intranet applications where those issues are not important?

 

I use exactly what I recommended: cookies, post and https. Additionally I require to re-verify password for critical operations and limit admin etc. access to known ip space. I haven't needed to, but if I would have to, I'd implement a servlet filter to disable url rewriting for session ids and another filter that would force a single ip to be used in the same session - both should very simple to do.

 

Kalle

 

-------- Original-Nachricht --------
> Datum: Mon, 26 May 2008 14:22:50 -0700
> Von: "Kalle Korhonen" <kalle.o.korhonen@...>
> An: users@...
> Betreff: Re: [trails-users] Trails Security unsecure ???

> On Mon, May 26, 2008 at 1:00 PM, Tobias Marx <superoverdrive@...>
> wrote:
>
> > The problem is though, that anyone can easily hijack your session this
> > way....you just need to visit another website and then, the URL
> including
> > your session id is included in the referrer url...so in this respect all
> > Trails security applications have a "security hole" if you dont do
> anything
> > else.....
>
>
> This is not Trails-specific, it's standard servlet-based application
> behavior.
>
>
> > There are some frameworks that also change the session id on every
> > request....anyway, but I still think cookies is the safest way - but
> there
> > is no way to disable them in the application...you can only use
> > jk_stripsession in Tomcat.
>
>
> If you are truly worried about this, do not rely on cookies being any more
> secure. The headers just as easily readable as the url. As I said, you can
> disable url rewriting by writing a simple servlet filter.
>
> Kalle
>
>
>
> > -------- Original-Nachricht --------
> > > Datum: Mon, 26 May 2008 11:56:43 -0700
> > > Von: "Kalle Korhonen" <kalle.o.korhonen@...>
> > > An: users@...
> > > Betreff: Re: [trails-users] Trails Security unsecure ???
> >
> > > Obviously session ids do not change with every request; that's why
> they
> > > are
> > > *session* ids. The servlet spec defines cookies and url rewriting as
> the
> > > methods for session tracking and it doesn't declare any way to
> instruct
> > > the
> > > container to only use either one or the other. Containers may allow to
> > > configure it. For example, Tomcat allows you to disable cookies, but
> not
> > > url
> > > re-writing
> (http://tomcat.apache.org/tomcat-5.5-doc/config/context.html
> > ).
> > > Naturally though, you can choose to not allow sessions at all. You can
> > > disable url re-writing manually with a simple filter, but passing in
> the
> > > jsessionid in the request header (as in cookie) isn't considerably
> more
> > > secure than passing it in the url. Use https only if you want to
> secure
> > > all
> > > communication to your site.
> > >
> > > Kalle
> > >
> > >
> > > On Mon, May 26, 2008 at 10:15 AM, Tobias Marx <superoverdrive@...>
> > > wrote:
> > >
> > > > Yes, this is what I did now...but what about the automatic
> session-id
> > > > fallback? Or is it possible to switch this off ?
> > > >
> > > > Session IDs are bad - unless they change with every
> request....and/or
> > > are
> > > > ip address related (but ips change, too).
> > > >
> > > >
> > > > -------- Original-Nachricht --------
> > > > > Datum: Mon, 26 May 2008 09:26:56 -0700
> > > > > Von: "Kalle Korhonen" <kalle.o.korhonen@...>
> > > > > An: users@...
> > > > > Betreff: Re: [trails-users] Trails Security unsecure ???
> > > >
> > > > > Use POST to send the login form via https. These certainly are
> easily
> > > > > configurable but not necessarily the best defaults when you first
> > > start
> > > > > developing a web application - which is why Trails and web app
> > > frameworks
> > > > > typically have the simplest options for demonstration purposes.
> > > > >
> > > > > Kalle
> > > > >
> > > > >
> > > > > On Mon, May 26, 2008 at 7:41 AM, Tobias Marx
> <superoverdrive@...>
> > > > > wrote:
> > > > >
> > > > > > There are some issues about Trails Security that might maybe
> > > > > > be configurable - I hope they are.
> > > > > >
> > > > > > By default, Trails Security is quite unsecure:
> > > > > >
> > > > > > 1. Username/password on the login page are passed via GET in the
> > URL
> > > > !!!
> > > > > > 2. If Cookies are disabled, Session IDs are used - that are
> easily
> > > > > > hijackable....
> > > > > >
> > > > > > Is there a workaround?
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > >
> > > > > > Tobias
> > > > > >
> > > > > >
> > > ---------------------------------------------------------------------
> > > > > > To unsubscribe from this list, please visit:
> > > > > >
> > > > > >    http://xircles.codehaus.org/manage_email
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe from this list, please visit:
> > > >
> > > >    http://xircles.codehaus.org/manage_email
> > > >
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> >    http://xircles.codehaus.org/manage_email
> >
> >
> >

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[Toby78]

Hello again!

If you disable cookies on a Trails security project (so it uses session ids) and you use the logout.svc link, it runs to a blank/empty page........

Is that only in my project like that or a general issue, e.g. due to the order of some hivemind filters?

Thanks!

Tobias

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Toby78]

I think I found a "bug" in:

org.trails.security.LogoutService.

If an error occurs in those lines:

        Cookie cookie = new Cookie("remembermetoken", "");
        cookie.setPath("/");
        cookie.setMaxAge(0);
        response.addCookie(cookie);

(e.g. cookies disabled), the user is not taken back to the "logout" page.

How can I overwrite the LogoutService in the meantime with a corrected version?

I can not find any references inside of hivemodule.xml or acegi-security.xml.......
to change the class for this "hook" ....

Thanks in advance for any help!

Tobias

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Kalle Korhonen-2]

Based on a quick glance at the code, it looks like a real issue. Can you please log a JIRA issue on it, I'll fix it for 1.2-SNAPSHOT?

Kalle

On Thu, Jun 5, 2008 at 2:14 AM, <superoverdrive@...> wrote:

Hello again!

If you disable cookies on a Trails security project (so it uses session ids) and you use the logout.svc link, it runs to a blank/empty page........

Is that only in my project like that or a general issue, e.g. due to the order of some hivemind filters?

Thanks!

Tobias

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[Toby78]

Whats the URL again?

It is not the Cookie part...it is the getRemoteUser() part that is sometimes empty...

I have created my own .jar file of Trails Security without the !=null condition and it works fine now.....

-------- Original-Nachricht --------
> Datum: Thu, 5 Jun 2008 08:28:14 -0700
> Von: "Kalle Korhonen" <kalle.o.korhonen@...>
> An: users@...
> Betreff: Re: [trails-users] Trails Security question / logout link

> Based on a quick glance at the code, it looks like a real issue. Can you
> please log a JIRA issue on it, I'll fix it for 1.2-SNAPSHOT?
>
> Kalle
>
>
> On Thu, Jun 5, 2008 at 2:14 AM, <superoverdrive@...> wrote:
>
> > Hello again!
> >
> > If you disable cookies on a Trails security project (so it uses session
> > ids) and you use the logout.svc link, it runs to a blank/empty
> page........
> >
> > Is that only in my project like that or a general issue, e.g. due to the
> > order of some hivemind filters?
> >
> > Thanks!
> >
> > Tobias
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> >    http://xircles.codehaus.org/manage_email
> >
> >
> >

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Kalle Korhonen-2]

http://jira.codehaus.org/browse/TRAILS, *but* if it's not the cookie, there's a good chance that your filters (in web.xml and/or acegi) are in wrong order or the request by-passes them. It's the Acegi remoteUserFilter that adds the user data to the request so getRemoteUser() returns the user. getRemoteUser() != null should stay in there, otherwise logoutservice would crash if a user uses it without logging in.

Kalle

On Thu, Jun 5, 2008 at 8:44 AM, Tobias Marx <superoverdrive@...> wrote:

Whats the URL again?

It is not the Cookie part...it is the getRemoteUser() part that is sometimes empty...

I have created my own .jar file of Trails Security without the !=null condition and it works fine now.....

-------- Original-Nachricht --------
> Datum: Thu, 5 Jun 2008 08:28:14 -0700
> Von: "Kalle Korhonen" <kalle.o.korhonen@...>
> An: users@...
> Betreff: Re: [trails-users] Trails Security question / logout link

> Based on a quick glance at the code, it looks like a real issue. Can you
> please log a JIRA issue on it, I'll fix it for 1.2-SNAPSHOT?
>
> Kalle
>
>
> On Thu, Jun 5, 2008 at 2:14 AM, <superoverdrive@...> wrote:
>
> > Hello again!
> >
> > If you disable cookies on a Trails security project (so it uses session
> > ids) and you use the logout.svc link, it runs to a blank/empty
> page........
> >
> > Is that only in my project like that or a general issue, e.g. due to the
> > order of some hivemind filters?
> >
> > Thanks!
> >
> > Tobias
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> >    http://xircles.codehaus.org/manage_email
> >
> >
> >

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[Alejandro Scandroli]

Hi

I have faced a similar issue when trying to integrate Trails with
Acegi and CAS. I had to rewrite the logout mechanism to use the
Acegi's LogoutFilter. Back then I thought about porting it to the
Trails trunk and I have filed
http://jira.codehaus.org/browse/TRAILS-110, but then I did't have the
time to do it.

Saludos.
Alejandro.

On Thu, Jun 5, 2008 at 6:08 PM, Kalle Korhonen
<kalle.o.korhonen@...> wrote:

> http://jira.codehaus.org/browse/TRAILS, *but* if it's not the cookie,
> there's a good chance that your filters (in web.xml and/or acegi) are in
> wrong order or the request by-passes them. It's the Acegi remoteUserFilter
> that adds the user data to the request so getRemoteUser() returns the user.
> getRemoteUser() != null should stay in there, otherwise logoutservice would
> crash if a user uses it without logging in.
>
> Kalle
>
>
> On Thu, Jun 5, 2008 at 8:44 AM, Tobias Marx <superoverdrive@...> wrote:
>>
>> Whats the URL again?
>>
>> It is not the Cookie part...it is the getRemoteUser() part that is
>> sometimes empty...
>>
>> I have created my own .jar file of Trails Security without the !=null
>> condition and it works fine now.....
>>
>> -------- Original-Nachricht --------
>> > Datum: Thu, 5 Jun 2008 08:28:14 -0700
>> > Von: "Kalle Korhonen" <kalle.o.korhonen@...>
>> > An: users@...
>> > Betreff: Re: [trails-users] Trails Security question / logout link
>>
>> > Based on a quick glance at the code, it looks like a real issue. Can you
>> > please log a JIRA issue on it, I'll fix it for 1.2-SNAPSHOT?
>> >
>> > Kalle
>> >
>> >
>> > On Thu, Jun 5, 2008 at 2:14 AM, <superoverdrive@...> wrote:
>> >
>> > > Hello again!
>> > >
>> > > If you disable cookies on a Trails security project (so it uses
>> > > session
>> > > ids) and you use the logout.svc link, it runs to a blank/empty
>> > page........
>> > >
>> > > Is that only in my project like that or a general issue, e.g. due to
>> > > the
>> > > order of some hivemind filters?
>> > >
>> > > Thanks!
>> > >
>> > > Tobias
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe from this list, please visit:
>> > >
>> > >    http://xircles.codehaus.org/manage_email
>> > >
>> > >
>> > >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email