iated.
Jeff
On Tue, Aug 11, 2009 at 8:20 AM, Jeff Longland wrote:
> It doesn't seem to be a session problem. If I take off the first
> ?wicket: in the URL, it will correctly load the ResultPage - so the
> session is still valid. I'm continuing to scratch my head as to why
> t
It doesn't seem to be a session problem. If I take off the first
?wicket: in the URL, it will correctly load the ResultPage - so the
session is still valid. I'm continuing to scratch my head as to why
there are two ?wicket params in the URL... Very frustrating.
On Mon, Aug 10, 2009 at 4:32 PM,
other containers, maybe it
> will help you to narrow the problem.
>
> -igor
>
> On Mon, Aug 10, 2009 at 12:31 PM, Jeff Longland
> wrote:
>> Not much in the way of clues... The ResultPage is being instantiated,
>> but instead of being rendered the HomePage is reloaded.
wrote:
> turn the logging to debug level and look at the logs for any clues.
>
> -igor
>
> On Mon, Aug 10, 2009 at 7:22 AM, Jeff Longland wrote:
>> I've been developing a Wicket app on GlassFish v2 and everything works
>> fine. But when I deploy the application to our pro
I've been developing a Wicket app on GlassFish v2 and everything works
fine. But when I deploy the application to our production server
which runs Sun Java App Server 7, setResponsePage() isn't working
properly. What's particularly infuriating is that I can see in the
database that the request is
> CAS redirects back to the callback url
>
> the url again causes your iauthorizationstrategy implementation to
> wake up. this time it sees the CAS token and lets the action proceed.
>
> -igor
>
> On Thu, Jun 18, 2009 at 7:51 PM, Jeff Longland wrote:
>> I'm r
I'm relatively new to Wicket and trying not to carry forward any
preconceived notions from other frameworks. What is the
suggested/preferred means of authenticating single sign-on requests
from another application? In particular, I'm thinking about MAC
(http://en.wikipedia.org/wiki/Message_authen
