As long as your shopping cart state is in your Wicket Session (not the HTTP
session) you should be okay. Session#replaceSession() invalidates the HTTP
session, but immediately binds the Wicket Session object to the new HTTP
session. Happy shopper, unhappy attacker. :)
On Mon, Mar 12, 2012 at 12:23
That's not always feasible - in respect to user experience. Just think of some
order process where e.g. you are asked to log in when doing a "checkout" (of
your shopping cart).
-Tom
Hielke Hoeve wrote:
> Webapplications should always invalidate the wicket session before
> authenticating.
alidate the wicket session before
> >> authenticating. (use Session.get().replaceSession() )
> >>
> >> See also: http://www.owasp.org/index.php/Session_Fixation
> >>
> >> Hielke
> >>
> >> -Original Message-
> >> From: Dan Re
henticating. (use Session.get().replaceSession() )
>>
>> See also: http://www.owasp.org/index.php/Session_Fixation
>>
>> Hielke
>>
>> -Original Message-
>> From: Dan Retzlaff [mailto:dretzl...@gmail.com]
>> Sent: maandag 5 maart 2012 3:53
>&g
n
>
> Hielke
>
> -Original Message-
> From: Dan Retzlaff [mailto:dretzl...@gmail.com]
> Sent: maandag 5 maart 2012 3:53
> To: users@wicket.apache.org
> Subject: Re: Wicket authentication: how to store user?
>
> Paolo, sessions are accessed with a JSESSIONID cook
@wicket.apache.org
Subject: Re: Wicket authentication: how to store user?
Paolo, sessions are accessed with a JSESSIONID cookie or query parameter
supplied with each request. It's not possible for one user to guess another
user's session ID, so the approach Martin describes is inherently secure
I mean that if you accept identifiers of external resources as parameters
(e.g. database primary keys), it is your responsibility to verify that the
authenticated user is authorized to access/modify that external resource.
Frameworks protect session data, but not such external resources.
On Wed, M
Alle lunedì 05 marzo 2012, Dan Retzlaff ha scritto:
> Paolo, sessions are accessed with a JSESSIONID cookie or query parameter
> supplied with each request. It's not possible for one user to guess another
> user's session ID, so the approach Martin describes is inherently secure.
Ok, thank you and
Paolo, sessions are accessed with a JSESSIONID cookie or query parameter
supplied with each request. It's not possible for one user to guess another
user's session ID, so the approach Martin describes is inherently secure.
(Just be careful with your authentication code and form/query parameter
vali
Alle sabato 03 marzo 2012, Martin Grigorov ha scritto:
> Hi,
>
> Save the logged in user id in the Session.
>
> MySession.java:
>
> private long userId;
>
> public User getUser() {
> return userService.getUserById(userId);
> }
>
>
> AnyPage.java:
> user = MySession.get().getUser();
>
Thank
Hi,
Save the logged in user id in the Session.
MySession.java:
private long userId;
public User getUser() {
return userService.getUserById(userId);
}
AnyPage.java:
user = MySession.get().getUser();
On Fri, Mar 2, 2012 at 9:38 PM, Paolo wrote:
> I use this code as base:
>
> http://wicketst
I use this code as base:
http://wicketstuff.org/wicket14/authentication/
I added registration and user/password sign-in and checking with database,
instead of simple "wicket" as user and password.
All works ok, but now I need in AdminPage to known which user is logged in.
How can I implement it
12 matches
Mail list logo
