You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Zeldor <pg...@gmail.com> on 2011/10/03 09:54:31 UTC

Authentication and sessions - the right way?

Hi,

I have a problem with designing authentication and session properly. I asked
for help some time ago, but I was not able to fix the problem.

I have a standard situation - I have an app that has bunch of pages and only
main page with login form should be accessible for everyone. Everything else
should be available after you log in. And some technical pages that should
be accessible for admins only.

So I want AuthenticatedApplication and AuthenticatedWebSession. I set main
page with login form in Application as the page that does not need
authentication. Then someone enters proper credentials and I set in Session
username [key] and whole User entity (transient) with proper role.

It all works fine on my computer, but when I deploy it, it stops working.
Session gets detached on the way and I cannot fetche the data to my models.
Yes, I keep user data in my session, I could do it with datastore queries,
but session is better solution on AppEngine. And problem would still be the
same pretty much.
There are 2 problems, which I don't really understand:

1. Session gets detached - where is it explained when and why it happens?
How should I properly initialise it? I thought that making
MySession.get().(...) would be enough... When user logs in, I do
"MySession.get().setUser(...)". Then user gets redirected to main app page,
where there are labels to display data
("MySession.get().getUser().getValueX()". Where is my mistake?

2. How to fetch data from Guice in Session? I have a Repository<User>
Inject, but when it is used in Session it throws nullpointer exception.
Should I have it in session at all? I guess repopulating user data like that
is not the best idea, I should probably just redirect him to login page
again, if session somehow losses data.

--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Authentication-and-sessions-the-right-way-tp3866840p3866840.html
Sent from the Users forum mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Authentication and sessions - the right way?

Posted by Carl-Eric Menzel <cm...@wicketbuch.de>.
On Mon, 3 Oct 2011 00:54:31 -0700 (PDT)
Zeldor <pg...@gmail.com> wrote:

> 2. How to fetch data from Guice in Session? I have a Repository<User>
> Inject, but when it is used in Session it throws nullpointer
> exception. Should I have it in session at all? I guess repopulating
> user data like that is not the best idea, I should probably just
> redirect him to login page again, if session somehow losses data.

Only components get automatic injection - to have the injection work in
session, put this in your Session constructor:

InjectorHolder.getInjector().inject(this);

Or for 1.5:

Injector.get().inject(this);

Carl-Eric
www.wicketbuch.de

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Authentication and sessions - the right way?

Posted by Marco Springer <ma...@gmail.com>.
I sort of use the same thing, storing the user in the Session.

Only I store a LoadableDetachableModel in the Session, representing the  
user.
In my scenario, the LDM is a custom Model and the key identifier is a Long  
number, but that shouldn't be a difference.
And the injection happens in the LDM as well.

This works fine in both development & deployment mode.

And if any data is updated in the database, Hibernate is smart enough to  
detect the changes and serves the latest data from the database. If no  
changes occurred, a cache call is made.


On Mon, 03 Oct 2011 10:19:28 +0200, Zeldor <pg...@gmail.com> wrote:

> So it's normal that I lose User data when I move from login to main page  
> and
> I will have to fetch it from db quite often.
>
> When will it happen? I have users browsing around my app, doing most  
> often
> nothing. Plenty of labels with gets. Will browsing like that trigger
> fetching user data from db? Or will that data be served from cache?
>
> Whenever anything changes data will be stored in db and page will reload.
> Will it fetch data from db again or serve them from cache?
>
> --
> View this message in context:  
> http://apache-wicket.1842946.n4.nabble.com/Authentication-and-sessions-the-right-way-tp3866840p3866875.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Authentication and sessions - the right way?

Posted by Zeldor <pg...@gmail.com>.
So it's normal that I lose User data when I move from login to main page and
I will have to fetch it from db quite often.

When will it happen? I have users browsing around my app, doing most often
nothing. Plenty of labels with gets. Will browsing like that trigger
fetching user data from db? Or will that data be served from cache? 

Whenever anything changes data will be stored in db and page will reload.
Will it fetch data from db again or serve them from cache?

--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Authentication-and-sessions-the-right-way-tp3866840p3866875.html
Sent from the Users forum mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Authentication and sessions - the right way?

Posted by Martin Grigorov <mg...@apache.org>.
On Mon, Oct 3, 2011 at 10:10 AM, Zeldor <pg...@gmail.com> wrote:
> But would it be possible to store User data in the session without having to
> fetch it from datastore on every request? My users don't interact with each
> other and they operate only on their own data. So it'd be most efficient to
> store User data in the session and interact with db only when some data is
> changed.
Only the first get for a request will fetch it from the DB, all
following gets will re-use the fetched User instance.
>
> --
> View this message in context: http://apache-wicket.1842946.n4.nabble.com/Authentication-and-sessions-the-right-way-tp3866840p3866866.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Authentication and sessions - the right way?

Posted by Zeldor <pg...@gmail.com>.
I'd say it's mostly a cache. 

>From estimates I can say that 80-90% of the time data will be read-only.
Only remaining 10-20% will be data manipulation.

My current implementation is that I use setters on data in Session and then
persist whole User. Like that:

MySession.get().getUser().setFree_land(MySession.get().getUser().getFree_land()
- building_houses);
Building.this.userRepo.persist(MySession.get().getUser());

--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Authentication-and-sessions-the-right-way-tp3866840p3866913.html
Sent from the Users forum mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Authentication and sessions - the right way?

Posted by Carl-Eric Menzel <cm...@wicketbuch.de>.
On Mon, 3 Oct 2011 10:31:38 +0200
Martin Grigorov <mg...@apache.org> wrote:


> > Yes, just put a field in your Session and add getter/setter.
> This is not good.
> This is error prone. This way you'll have to keep the instance in the
> Session in sync with the data DB. Additionally the memory size will
> increase for no reason. Select by primary key (user id) is fast
> operation.

That depends on what you're doing. One possibility is that it's mostly
read-only data, then it can be a speed boost to just keep that stuff in
the session.

Of course, if you have writes all over the place, then that could
become messy. An alternative could be a model implementation that reads
from the session and updates both session and DB on a write. That would
basically be a cache then.

Selecting by user id is *probably* fast, but it depends on what other
data needs to be joined to it. It might also be a more costly operation.

Carl-Eric
www.wicketbuch.de

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Authentication and sessions - the right way?

Posted by Marco Springer <ma...@gmail.com>.
Each browser opens up a new session, that's no actual problem.
Sessions are pretty thread safe (correct me if I'm wrong) when they're  
accessed from request threads (normal Wicket application flow).
If Browser #1 changes something to user data or some other db data, and  
Browser #2 fires a new request, the data is instantly reloaded for that  
Browser #2.
Though a problem would be if both instances submit the same type of data,  
the last request performed is the one that's stored.
Although there are techniques to overcome this problem as well. Something  
like:  
http://docs.jboss.org/hibernate/core/3.5/reference/en/html/transactions.html#transactions-optimistic-manual

Some sample code (don't mind the fake names and I simplified the code to  
just show the necessary):
public class CustomSession<T extends ModelObject> extends WebSession {
   private GenericDetachableModel<T> credentialLDM; // T as the user can be  
of 2 object types in our situation
   public static CustomSession get() {
     return (CustomSession) Session.get();
   }

   public void setUser(GenericDetachableModel<T> credentialLDM) {
     this.credentialLDM = credentialLDM;
   }

   public synchronized GenericDetachableModel<T> getUser() {
     return credentialLDM;
   }
}

And in the code where I need the user object I just make a call to:  
"CustomSession.get().getUser().getObject()";
This will always retrieve the latest user instance in the database and is  
valid during a complete Request.
And just as Martin said, put a memcache in between and the database  
requests are minimized, if not already loaded from the Hibernate cache.

The LDM would be like:
public class GenericDetachableModel<T extends ModelObject> extends  
LoadableDetachableModel<T> {

   @SpringBean(name = "service")
   private Service service;

   public GenericDetachableModel(T entity) {
     this.entityId = entity.getId();

     if (entity instanceof HibernateProxy) {
       this.entityClass =
               (Class) ((HibernateProxy)  
entity).getHibernateLazyInitializer().getImplementation().getClass();
     } else {
       this.entityClass = (Class) entity.getClass();
     }

     InjectorHolder.getInjector().inject(this);
   }

   @Override
   protected T load() {
     return service.getObject(entityClass, entityId);
   }
}

I do have some more session functionality to mingle with the user object,  
but they are not important in this matter.


On Mon, 03 Oct 2011 10:41:15 +0200, Zeldor <pg...@gmail.com> wrote:

> Marco:
>
> And it works without problems? There is no issue with user trying to log
> from 2 browser on same time, trying to cheat the system? I am just  
> wondering
> if there is any risk of that.
> How does your code look then in session and how do you fetch your data?
>
> Martin:
>
> I was trying to save on costs, where on AppEngine you are billed for  
> every
> DB query, while memcache is pretty much free. Is it really hard to keep
> session data in sync? Only that user can modify his data.
>
> --
> View this message in context:  
> http://apache-wicket.1842946.n4.nabble.com/Authentication-and-sessions-the-right-way-tp3866840p3866906.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Authentication and sessions - the right way?

Posted by Martin Grigorov <mg...@apache.org>.
On Mon, Oct 3, 2011 at 10:41 AM, Zeldor <pg...@gmail.com> wrote:
> Marco:
>
> And it works without problems? There is no issue with user trying to log
> from 2 browser on same time, trying to cheat the system? I am just wondering
> if there is any risk of that.
> How does your code look then in session and how do you fetch your data?
>
> Martin:
>
> I was trying to save on costs, where on AppEngine you are billed for every
> DB query, while memcache is pretty much free. Is it really hard to keep
> session data in sync? Only that user can modify his data.
Then just tell your Repository to ask first Memcache and if there is a
miss then the actual DB.
>
> --
> View this message in context: http://apache-wicket.1842946.n4.nabble.com/Authentication-and-sessions-the-right-way-tp3866840p3866906.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Authentication and sessions - the right way?

Posted by Zeldor <pg...@gmail.com>.
Marco:

And it works without problems? There is no issue with user trying to log
from 2 browser on same time, trying to cheat the system? I am just wondering
if there is any risk of that. 
How does your code look then in session and how do you fetch your data? 

Martin:

I was trying to save on costs, where on AppEngine you are billed for every
DB query, while memcache is pretty much free. Is it really hard to keep
session data in sync? Only that user can modify his data.

--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Authentication-and-sessions-the-right-way-tp3866840p3866906.html
Sent from the Users forum mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Authentication and sessions - the right way?

Posted by Bas Gooren <ba...@iswd.nl>.
In our apps we use a request-scoped guice provider.

This makes the scoping explicit, and as an added benefit you get looser 
coupling:

@Inject
Provider<User> userProvider;

When no user is logged in, we return a Null object (which also works 
since we use domain driven design extensively).
E.g. User.NONE.

In case we have more complex auth-related context, we inject a 
SecurityContext where it's needed.
SecurityContext is a custom class which contains the Provider<User> and 
other auth-related functionality.

Op 3-10-2011 17:33, schreef Dan Retzlaff:
> Isn't it a bad idea to keep any non-thread-safe objects in the session?
> Sharing entities sounds particularly risky since any persistence session
> other than the original that, say, tries to initialize a lazy collection
> will result in a runtime exception.
>
> Because of this, our application maintains the user primary key in the
> Wicket Session (using metadata), but it gets loaded through a RequestCycle
> subclass. No need to worry about concurrent access or detach() logic there.
>
> On Mon, Oct 3, 2011 at 1:31 AM, Martin Grigorov<mg...@apache.org>wrote:
>
>> On Mon, Oct 3, 2011 at 10:24 AM, Carl-Eric Menzel<cm...@wicketbuch.de>
>> wrote:
>>> On Mon, 3 Oct 2011 01:10:58 -0700 (PDT)
>>> Zeldor<pg...@gmail.com>  wrote:
>>>
>>>> But would it be possible to store User data in the session without
>>>> having to fetch it from datastore on every request? My users don't
>>>> interact with each other and they operate only on their own data. So
>>>> it'd be most efficient to store User data in the session and interact
>>>> with db only when some data is changed.
>>> Yes, just put a field in your Session and add getter/setter.
>> This is not good.
>> This is error prone. This way you'll have to keep the instance in the
>> Session in sync with the data DB. Additionally the memory size will
>> increase for no reason. Select by primary key (user id) is fast
>> operation.
>>> Carl-Eric
>>> www.wicketbuch.de
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>

Re: Authentication and sessions - the right way?

Posted by Dan Retzlaff <dr...@gmail.com>.
Isn't it a bad idea to keep any non-thread-safe objects in the session?
Sharing entities sounds particularly risky since any persistence session
other than the original that, say, tries to initialize a lazy collection
will result in a runtime exception.

Because of this, our application maintains the user primary key in the
Wicket Session (using metadata), but it gets loaded through a RequestCycle
subclass. No need to worry about concurrent access or detach() logic there.

On Mon, Oct 3, 2011 at 1:31 AM, Martin Grigorov <mg...@apache.org>wrote:

> On Mon, Oct 3, 2011 at 10:24 AM, Carl-Eric Menzel <cm...@wicketbuch.de>
> wrote:
> > On Mon, 3 Oct 2011 01:10:58 -0700 (PDT)
> > Zeldor <pg...@gmail.com> wrote:
> >
> >> But would it be possible to store User data in the session without
> >> having to fetch it from datastore on every request? My users don't
> >> interact with each other and they operate only on their own data. So
> >> it'd be most efficient to store User data in the session and interact
> >> with db only when some data is changed.
> >
> > Yes, just put a field in your Session and add getter/setter.
> This is not good.
> This is error prone. This way you'll have to keep the instance in the
> Session in sync with the data DB. Additionally the memory size will
> increase for no reason. Select by primary key (user id) is fast
> operation.
> >
> > Carl-Eric
> > www.wicketbuch.de
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: Authentication and sessions - the right way?

Posted by Martin Grigorov <mg...@apache.org>.
On Mon, Oct 3, 2011 at 10:24 AM, Carl-Eric Menzel <cm...@wicketbuch.de> wrote:
> On Mon, 3 Oct 2011 01:10:58 -0700 (PDT)
> Zeldor <pg...@gmail.com> wrote:
>
>> But would it be possible to store User data in the session without
>> having to fetch it from datastore on every request? My users don't
>> interact with each other and they operate only on their own data. So
>> it'd be most efficient to store User data in the session and interact
>> with db only when some data is changed.
>
> Yes, just put a field in your Session and add getter/setter.
This is not good.
This is error prone. This way you'll have to keep the instance in the
Session in sync with the data DB. Additionally the memory size will
increase for no reason. Select by primary key (user id) is fast
operation.
>
> Carl-Eric
> www.wicketbuch.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Authentication and sessions - the right way?

Posted by Carl-Eric Menzel <cm...@wicketbuch.de>.
On Mon, 3 Oct 2011 01:10:58 -0700 (PDT)
Zeldor <pg...@gmail.com> wrote:

> But would it be possible to store User data in the session without
> having to fetch it from datastore on every request? My users don't
> interact with each other and they operate only on their own data. So
> it'd be most efficient to store User data in the session and interact
> with db only when some data is changed. 

Yes, just put a field in your Session and add getter/setter.

Carl-Eric
www.wicketbuch.de

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Authentication and sessions - the right way?

Posted by Zeldor <pg...@gmail.com>.
But would it be possible to store User data in the session without having to
fetch it from datastore on every request? My users don't interact with each
other and they operate only on their own data. So it'd be most efficient to
store User data in the session and interact with db only when some data is
changed. 

--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Authentication-and-sessions-the-right-way-tp3866840p3866866.html
Sent from the Users forum mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Authentication and sessions - the right way?

Posted by Martin Grigorov <mg...@apache.org>.
Hi,

On Mon, Oct 3, 2011 at 9:54 AM, Zeldor <pg...@gmail.com> wrote:
> Hi,
>
> I have a problem with designing authentication and session properly. I asked
> for help some time ago, but I was not able to fix the problem.
>
> I have a standard situation - I have an app that has bunch of pages and only
> main page with login form should be accessible for everyone. Everything else
> should be available after you log in. And some technical pages that should
> be accessible for admins only.
>
> So I want AuthenticatedApplication and AuthenticatedWebSession. I set main
> page with login form in Application as the page that does not need
> authentication. Then someone enters proper credentials and I set in Session
> username [key] and whole User entity (transient) with proper role.
>
> It all works fine on my computer, but when I deploy it, it stops working.
> Session gets detached on the way and I cannot fetche the data to my models.
> Yes, I keep user data in my session, I could do it with datastore queries,
> but session is better solution on AppEngine. And problem would still be the
> same pretty much.
> There are 2 problems, which I don't really understand:
>
> 1. Session gets detached - where is it explained when and why it happens?
> How should I properly initialise it? I thought that making
> MySession.get().(...) would be enough... When user logs in, I do
> "MySession.get().setUser(...)". Then user gets redirected to main app page,
> where there are labels to display data
> ("MySession.get().getUser().getValueX()". Where is my mistake?
The Wicket Session is detached at the end of the request processing.
At this point the Wicket session is serialized as byte array in the
http session.
For the next request the Wicket session is deserialized from the http
session and here your User object is null (because it is transient).
This is all fine!
>
> 2. How to fetch data from Guice in Session? I have a Repository<User>
> Inject, but when it is used in Session it throws nullpointer exception.
> Should I have it in session at all? I guess repopulating user data like that
> is not the best idea, I should probably just redirect him to login page
> again, if session somehow losses data.
Declare another field in your Session implementation:
private @Inject Repository<User> repository;

And do: InjectorHolder.get().inject(this) (Wicket 1.5 syntax) in your
Session contructor. This will inject serializable proxy which will be
properly serialized and deserialized when needed.

Now remove #setUser() and implement #getUser() method in YourSession.
If the User field is non-null then just return it otherwise use the
user id and with the repository fetch and created the User instance.
>
> --
> View this message in context: http://apache-wicket.1842946.n4.nabble.com/Authentication-and-sessions-the-right-way-tp3866840p3866840.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Authentication and sessions - the right way?

Posted by Carl-Eric Menzel <cm...@wicketbuch.de>.
On Mon, 3 Oct 2011 00:54:31 -0700 (PDT)
Zeldor <pg...@gmail.com> wrote:

> It all works fine on my computer, but when I deploy it, it stops
> working. Session gets detached on the way and I cannot fetche the
> data to my models. Yes, I keep user data in my session, I could do it
> with datastore queries, but session is better solution on AppEngine.
> And problem would still be the same pretty much.
> There are 2 problems, which I don't really understand:

Can you show the relevant code?

Carl-Eric
www.wicketbuch.de

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org