Thank you all.
That's what I was prepared to do. But because I don't know very much about
security, I was wondering if there any risk to let parameters visible in the
request. I will follow your solution Thorsten.
But if anyone has more advices, they should always be helpful !
Thanks.

Sebastien


On 2/1/07, Thorsten Schäfer <Uni@(protected):
>
> Ahh,
>
> I had a similar question a couple of days before. If you request the
> data from a DB, you may change your query, e.g.,
> SELECT * from picture where id=:id and userId=:userId
> to ensure that you may only see your photos. In our implementation, we
> kept the database queries and always retrived the business object, but
> then compared the business objects' user to the user logged in (and
> throw an Exception if they are not equal).
>
> HTH,
>
> Thorsten
>
> > -----Original Message-----
> > From: Sébastien LABEY [mailto:sebastien.labey@(protected)]
> > Sent: Wednesday, January 31, 2007 8:57 PM
> > To: Struts Users Mailing List
> > Subject: Re: [S2] User authentication best practice (2nd time...)
> >
> > Thanks for your answer.
> > Maybe I'm not very clear (sorry for my english). Let's imagine the
> > following
> > request to access the page to update the user informations :
> > /myApp/userPrepareUpdate.action?id=1234
> > Anyone can modify the request and change 1234 to any other id and so
> > access
> > to the informations of another user. That's why I have to check that
> the
> > parameter "id" passed in the request has the same value than the "id"
> in
> > the
> > user object stored in session.
> > That can be the same for the page that redirects to any other object
> of
> > the
> > application that does not belong to the user (imagine photo
> gallery)...
> > So did I miss something? I'm sure yes...
> >
> > Sebastien
> >
> >
> >
> > On 1/31/07, Thorsten Schäfer <Uni@(protected):
> > >
> > > Hi,
> > >
> > > Why do you care about the information in the request? Typically, you
> > > have a login page and the corresponding action stores the user
> object
> > > into the session. In all subsequent requests, you can check the user
> > > object in the session to determine which user did log in. This works
> for
> > > S1, but I'd think that it's the same in S2.
> > >
> > > Cheers,
> > >
> > > Thorsten
> > >
> > > > -----Original Message-----
> > > > From: Sébastien LABEY [mailto:sebastien.labey@(protected)]
> > > > Sent: Wednesday, January 31, 2007 8:22 PM
> > > > To: Struts mailing list
> > > > Subject: [S2] User authentication best practice (2nd time...)
> > > >
> > > > Hi all (sorry for the previous unterminated mail),
> > > >
> > > > I would like to know if S2 provides a solution to manage user
> > > > authentication.
> > > > I also would like to know if someone could lead me to best
> practice
> > > for
> > > > user
> > > > creation / authentication to a web application. I'm worried about
> > > security
> > > > after the user has logged in, because of the parameters that
> appear in
> > > the
> > > > request. For example, the request that leads to user informations
> > > > modification shows the id of this user in the request, so I've to
> > > control
> > > > that the user id in the request is the same than the one in
> session
> > > (in
> > > > the
> > > > user object stored in session after login).
> > > > Do you have some best practices to help me...?
> > > >
> > > > thanks in advance
> > > >
> > > > Sebastien
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscribe@(protected)
> > > For additional commands, e-mail: user-help@(protected)
> > >
> > >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@(protected)
> For additional commands, e-mail: user-help@(protected)
>
>