@lists.jasig.org
Subject: Re: [cas-user] CAS OAuth Support 3.5.2 - Working with service
parameter.
Hi,
I don't remember how I came to test *RequestContextUtil.getTheme*, but
you're right, the default *ServiceThemeResolver* is based on the
service query parameter and not on the service
at 8:23 AM
To: cas-user@lists.jasig.orgmailto:cas-user@lists.jasig.org
cas-user@lists.jasig.orgmailto:cas-user@lists.jasig.org
Subject: Re: [cas-user] CAS OAuth Support 3.5.2 - Working with service
parameter.
Hi,
Thanks for testing. Indeed, the HttpServletRequestWrapper is a good solution.
Would
@lists.jasig.org cas-user@lists.jasig.org
Subject: Re: [cas-user] CAS OAuth Support 3.5.2 - Working with service
parameter.
Hi,
Thanks for testing. Indeed, the HttpServletRequestWrapper is a good
solution.
Would you mind opening a Github issue to track this bug ? I will fix it
for 4.1
or clarification you could provide.
-- Jonathan
From: Jérôme LELEU lel...@gmail.com
Reply-To: cas-user@lists.jasig.org cas-user@lists.jasig.org
Date: Wednesday, June 18, 2014 at 9:04 AM
To: cas-user@lists.jasig.org cas-user@lists.jasig.org
Subject: Re: [cas-user] CAS OAuth Support 3.5.2
@lists.jasig.org
Subject: Re: [cas-user] CAS OAuth Support 3.5.2 - Working with service
parameter.
Hi,
I don't remember how I came to test RequestContextUtil.getTheme, but you're
right, the default ServiceThemeResolver is based on the service query
parameter and not on the service in the webflow
@lists.jasig.org
Subject: Re: [cas-user] CAS OAuth Support 3.5.2 - Working with service
parameter.
Hi,
I don't remember how I came to test *RequestContextUtil.getTheme*, but
you're right, the default *ServiceThemeResolver* is based on the
service query parameter and not on the service
@lists.jasig.orgmailto:cas-user@lists.jasig.org
Subject: Re: [cas-user] CAS OAuth Support 3.5.2 - Working with service
parameter.
Hi,
Indeed, a logger.error would have been appreciated in the catch
(TicketException part.
Yes, the restore methods are the ones the comment is referring to. And they
are called before
Hi,
Indeed, a logger.error would have been appreciated in the catch
(TicketException part.
Yes, the restore methods are the ones the comment is referring to. And
they are called before the exception is thrown: all parameters should be
restored.
I've spent some time to perform a full test and
Thanks for taking the time to look into this issue. I'll keep digging to see
if I'm doing anything wrong. Thanks.
--
You are currently subscribed to cas-user@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
The exception I got appears to have been caught and handled by
CAS/OAuthAction. There's not much of a trace in the log.
OAuthAction.doExecute:
.
.
.
} catch (final TicketException e) {
return error();
}
cas.log
2014-06-16 18:07:07,023 INFO
Hi,
In fact, the service parameter should be handled properly. It it saved
before the redirection to the external identity provider and restored after
the successful delegated authentication.
So you shouldn't have any problem with keeping your service.
It should be properly handled in case of an
: [cas-user] CAS OAuth Support 3.5.2 - Working with service
parameter.
Hi,
In fact, the service parameter should be handled properly. It it saved before
the redirection to the external identity provider and restored after the
successful delegated authentication.
So you shouldn't have any problem
By the way, for now I've been able to work around this issue by injecting my
service parameter value into the callback url that I sent to the third-party
oauth server.
--
You are currently subscribed to cas-user@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or
13 matches
Mail list logo
