Did you find root of the problem? Just curious :)
Good luck
On Tue, Jan 11, 2011 at 11:00 PM, Pepijn Schmitz <capt...@chaos.demon.nl>wrote:
> Hi,
>
> Thanks! But I don't think that's it. We're already using HTTPS, but also
> that would not explain how the correct application state object can be on
> the HttpSession, even though Tapestry injected the wrong one...
>
> We are using Apache 2 using mod_proxy as a front-end though. Apache takes
> care of the SSL and forwards the requests to Glassfish over HTTP. I'll look
> into the possibility that something is going wrong there, although it seems
> unlikely due to the above reason...
>
> Cheers,
> Pepijn
>
>
> On 11-01-11 19:04, Koka Kiknadze wrote:
>
>> I did have exactly similar problem couple of years ago - JSF app worked
>> fine
>> from intranet, but messed up user sessions when accessed from WAN side.
>>
>> So initial suspect was the squid proxy configuration of our ISP. The
>> problem
>> disappeared as soon as we turned encryption on for the whole site (so that
>> proxy could not mess things up). Well, as the performance was acceptable
>> even with HTTPS we just left everything as is.
>>
>> Hence I'd suggest temporarily requiring HTTPS for the whole site and if
>> the
>> problem disappears, you'll know for sure it's not your application or
>> tapestry to be blamed.
>>
>> Good luck.
>>
>>
>>
>>
>> On Tue, Jan 11, 2011 at 8:37 PM, Pepijn Schmitz<tapes...@chaos.demon.nl
>> >wrote:
>>
>> Hi everyone,
>>>
>>> I'm having a bizarre problem with Tapestry, and I'm hoping someone here
>>> might be able to point me to a solution. Before I go into detail I'd like
>>> to
>>> describe the problem generally, in the hopes that it might be a known
>>> problem or someone may have encountered something similar.
>>>
>>> The problem is that Tapestry 4.1.6 sometimes injects the wrong
>>> application
>>> state object on my pages! As you can imagine, this plays havoc with my
>>> application, with users seeing other users' details, or even worse,
>>> changing
>>> other users' information! It's a support and security nightmare.
>>>
>>> I'm using Tapestry 4.1.6, and I'm using annotations instead of XML files.
>>> My pages all descend from a base class:
>>>
>>> public abstract SupplierDNAPage extends BasePage {
>>> @InjectState
>>> public abstract SupplierDnaSession getSupplierDnaSession();
>>>
>>> @InjectStateFlag
>>> public abstract boolean getSupplierDnaSessionExists();
>>>
>>> ...
>>> }
>>>
>>> hivemodule.xml contains the following:
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <module id="com.supplierdna" version="0.0.0">
>>> <contribution configuration-id="tapestry.state.ApplicationObjects">
>>> <state-object name="supplier-dna-session" scope="session">
>>> <create-instance class="com.supplierdna.logic.SupplierDnaSession"/>
>>> </state-object>
>>> </contribution>
>>> ...
>>> </module>
>>>
>>> SupplierDNA is the name of the company I'm writing this for. As I
>>> understand it, this is the correct way of using application state
>>> objects.
>>> And most of the time, it works perfectly. When testing locally I have no
>>> problems with wrong application state being injected, and our demo system
>>> also doesn't have the problem.
>>>
>>> The problems seem to start when the server is heavily loaded. Then,
>>> sometimes, getSupplierDnaSession() will return an application state
>>> object
>>> from a different session!!!
>>>
>>> I have verified this by adding a pageBeginRender() listener method to the
>>> base class, and a client address property to the session. The listener
>>> method checks whether the client address stored on the session it gets
>>> from
>>> Tapestry is the same as the client address from the current request, and
>>> throws an exception if this is not the case. On our production server,
>>> this
>>> happens dozens of times a day!
>>>
>>> The method also directly retrieves the application state object from the
>>> HttpSession and compares it to the one it got from Tapestry, and it turns
>>> out that the application state object on the HttpSession is the correct
>>> one,
>>> but somehow Tapestry is injecting a different one! This seems to rule out
>>> the web container as being the culprit (which is Glassfish 2 update 2, in
>>> this case).
>>>
>>> Obviously this is a complex problem with a potentially huge number of
>>> contributing factors, but first I'd just like to know whether this sounds
>>> familiar to anyone? Is there a known problem with Tapestry which could
>>> cause
>>> this? Has anyone ever experienced something similar? Many thanks in
>>> advance
>>> for any help you can give me!
>>>
>>> Kind regards,
>>> Pepijn Schmitz
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>
>>>
>>>
>
>
