this has nothing to do with how many servers you are running most containers will create a new sessionid for https requests and mark that cookie as secure - so it cannot be hijacked.
so your app sees one session for http urls and another for https urls - all without the application actually knowing anything about it. a possible solution can be to force session creation on first access to http url. there was another thread about this very recently, you might want to search for it. -igor On Tue, Jun 16, 2009 at 12:56 PM, Martin Makundi<[email protected]> wrote: >> as far as wicket is concerned it does the best it can. when the >> session is gone we have no state information at all and the only thing >> we can do is display the page expired page. what exactly is >> "unprofessional" about this. > > Well.. this crash :) It is not very 'graceful', maybe better wording > than professionality.... > >> btw, is your login page https? this may be caused by the fact that you >> will have two different session ids: one secure and one not secure. > > This is actually true... however I have a single jetty listening to > :8080 so I would presume it sees a single session. > > ** > Martin > >> On Tue, Jun 16, 2009 at 12:21 PM, Martin >> Makundi<[email protected]> wrote: >>> I have a feeling this has something to do with the littlebit >>> 'unprofessional' way of wicket's dealing with session expiration on >>> stateful pages. Wicket sort of deals with session expiration like if >>> it was a fatal state.. while it is just daily bloody normal ;) >>> Anyways... I will look into this, it's bugged me for 1 year now and I >>> have managed to override it but not solve it. >>> >>> ** >>> Martin >>> >>> 2009/6/16 Igor Vaynberg <[email protected]>: >>>> so the curiosity is why is wicket trying to submit the loginform to >>>> the mainpage? i dont think i have seen anything like this before. if >>>> you can find a way to reproduce it we will be happy to fix it. >>>> >>>> -igor >>>> >>>> On Tue, Jun 16, 2009 at 11:54 AM, Martin >>>> Makundi<[email protected]> wrote: >>>>> No. MainPage is the page the user has probably bookmarked or something.. >>>>> it >>>>> is the page after successful login. >>>>> ** >>>>> Martin >>>>> >>>>> 2009/6/16 Igor Vaynberg <[email protected]> >>>>> >>>>>> is your LoginPage the com.domain.view.application.MainPage ? >>>>>> >>>>>> -igor >>>>>> >>>>>> On Tue, Jun 16, 2009 at 9:54 AM, Martin >>>>>> Makundi<[email protected]> wrote: >>>>>> > I am not actually sure how to repeat this bug, this is what I see on >>>>>> > the production log. >>>>>> > >>>>>> > ** >>>>>> > Martin >>>>>> > >>>>>> > 2009/6/16 Igor Vaynberg <[email protected]>: >>>>>> >> IFormSubmitListener? so this happens when you submit the login page? >>>>>> >> >>>>>> >> -igor >>>>>> >> >>>>>> >> On Tue, Jun 16, 2009 at 9:30 AM, Martin >>>>>> >> Makundi<[email protected]> wrote: >>>>>> >>>> IIRC, for this purpose I had written a separate expired page but I >>>>>> >>>> had >>>>>> >>>> thrown a new restartresponseexception(LoginPage.class) which was >>>>>> working >>>>>> >>>> fine with wicket 1.3.4. >>>>>> >>> >>>>>> >>> So is there a bug with the pageparameters for a stateful page? They >>>>>> >>> should be thrown away when pageExpired occurs (this happens >>>>>> >>> automatically with restartresponseexception?)? >>>>>> >>> >>>>>> >>> Here is some more of the stack: >>>>>> > >>>>>> > --------------------------------------------------------------------- >>>>>> > To unsubscribe, e-mail: [email protected] >>>>>> > For additional commands, e-mail: [email protected] >>>>>> > >>>>>> > >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
