Hey, noticed that the one-time "backup" codes for Google Authenticator do
not work on our 5.1.5 install. They are called "scratchcodes" in the
database. Looks like the cas-server-support-gauth-core passes the token
verification to the com.warrenstrange.auth package which when I checked the
Also having a similar issue:
Caused by: java.lang.ClassCastException:
org.opensaml.saml.ext.saml2mdui.impl.InformationURLImpl cannot be cast to
org.opensaml.saml.saml2.metadata.LocalizedName
at
Was using globally_quoted_identifiers successfully in 5.1.x, now in 5.3.x,
seems like it does not follow the setting and the queries are not being
quoted properly. Any ideas?
--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines:
The issue with google zxing and ANDROID_HOME seems to only happen when
building on Windows. I couldn't find a solid answer as to the impact on the
final build or any workarounds. I ended up moving my build environment to
linux to get building working much more smoothly and without errors.
On
Hi Danny.
Noticing the same thing just now. Any workaround? I'll let you know if I
end up finding one.
Thanks.
On Thursday, September 27, 2018 at 4:08:19 PM UTC-4, Danny wrote:
>
> I've been playing around sending logs to a Graylog server using the
> GelfLayout mechanism. It's working...too
Added a static value for the password field to hide it:
On Monday, October 22, 2018 at 10:02:32 PM UTC-4, JF Poulin wrote:
>
> Hi Danny.
>
> Noticing the same thing just now. Any workaround? I'll let you know if I
> end up finding one.
>
> Thanks.
>
> On Thursday, Se
'll go back and try it
> again.
>
> Thanks
>
> On Monday, October 22, 2018 at 9:08:15 PM UTC-5, JF Poulin wrote:
>>
>> Added a static value for the password field to hide it:
>>
>>
>>
>>
>>
--
- Website: https://apereo.github.io/cas
-
PM UTC-4, JF Poulin wrote:
>
> Was using globally_quoted_identifiers successfully in 5.1.x, now in 5.3.x,
> seems like it does not follow the setting and the queries are not being
> quoted properly. Any ideas?
>
--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: ht
I've traced the problem to the SamlServiceFactory class. It seems as though
service and requestBody are always null. Trying to debug the issue.
--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions:
After a lot of debugging, I have discovered that the XML is not being
properly inflated in AbstractSaml20ObjectBuilder at line 442:
CompressionUtils.inflate(decodedBytes);
java is complaining about the zip header
--
- Website: https://apereo.github.io/cas
- Gitter Chatroom:
the code for inflate back.
On Wednesday, December 12, 2018 at 3:48:39 PM UTC-5, JF Poulin wrote:
>
> After a lot of debugging, I have discovered that the XML is not being
> properly inflated in AbstractSaml20ObjectBuilder at line 442:
> CompressionUtils.inflate(decodedByte
Upgraded my version of CAS to 5.3.6 from 5.1.3. In the new version CAS
seems to be ignoring the SAMLRequest parameter being generated by Google
Apps.
When a user logs in, they just get redirected to the usual successful login
page instead of being sent back to Google.
I'm building my own
Running into this issue on v5.1.9 can anyone confirm that it is fixed in
v5.3.x? If I wanted to patch it in 5.1.x, where should I look?
Thanks!
On Thursday, April 12, 2018 at 10:55:32 AM UTC-4, Bergner, Arnold wrote:
>
> We’re facing the same issue on 5.2.2, tomcat 8.0.
>
>
>
> I’ve also
Running into this issue in v5.1.9. Can anybody confirm that it was fixed in
v5.3.x? If I wanted to patch v5.1.x, where should I look in the code?
Thanks!
On Monday, August 28, 2017 at 10:02:48 AM UTC-4, Song, Doe-Hyun wrote:
>
> Good Morning All,
>
>
>
> Since we go to production with CAS
, March 6, 2019 at 7:58:19 AM UTC-5, dfisher wrote:
>
> On Mon, Mar 4, 2019 at 2:09 PM JF Poulin > wrote:
>
>> I am having issues where CAS just keeps creating more and more LDAP
>> threads without always closing the old ones. System eventually blocks CAS
>> from creat
I am having issues where CAS just keeps creating more and more LDAP threads
without always closing the old ones. System eventually blocks CAS from
creating more threads which results in cannot create new native thread
errors. Is there a way to ensure that threads time out after some time
I was scratching my head about this last night and I seem to have figured
out some things. The documentation provided isn't clear as it references
the path /etc/cas/config/saml/metadata which is different than the default
path /etc/cas/saml
Then you need to create a directory inside that path
The code that handles this is located in FileSystemSamlIdPMetadataLocator >
getMetadataArtifact(...)
On Thursday, September 9, 2021 at 7:51:14 AM UTC-4 JF Poulin wrote:
> I was scratching my head about this last night and I seem to have figured
> out some things. The documentation
18 matches
Mail list logo
