Re: [cas-user] NullPointerException in InitialAuthenticationAttemptWebflowEventResolver.java in CAS 5.3.10

> Martin, > > Looking on github, the current 5.3.x version id 5.3.9 from 04 March. > > Ray > > On Sat, 2019-05-11 at 06:12 -0700, Martin Böhmer wrote: > > I can reproduce the following NPE when logging into Service A via CAS and > then trying to access Service B by calling B&#

[cas-user] NullPointerException in InitialAuthenticationAttemptWebflowEventResolver.java in CAS 5.3.10

I can reproduce the following NPE when logging into Service A via CAS and then trying to access Service B by calling B's URL. 2019-05-10 22:50:34,980 WARN > [org.apereo.cas.web.flow.resolver.impl.InitialAuthenticationAttemptWebflowEventResolver] > > - > java.lang.NullPointerException: null >

Re: [cas-user] CAS 5.3.8 - Password Management - JDBC - Password's change does not update DB

I experienced the exact same behaviour and solved it by setting autocommit = true. Don't think it is your IDE causing the problem. Am Donnerstag, 9. Mai 2019 10:38:23 UTC+2 schrieb Nicola Boldrin: > > Hi Ray, > I've verified that the SQL is ok. After trying the > cas.authn.pm.jdbc.autocommit pro

[cas-user] Re: NPE in InitialAuthenticationAttemptWebflowEventResolver.java in CAS 5.3.10

Something went wrong with the subject of my initial post: *The affected CAS version is 5.3.10* not 3.9.10! Meanwhile I have some more information: The error I experience may point to a problem somewhere else in CAS 5.3.10. Before I deployed the release version I ran a snapshot version from April

[cas-user] NPE in InitialAuthenticationAttemptWebflowEventResolver.java in CAS 3.9.10

I can reproduce the following NPE when logging into Service A via CAS and then trying to access Service B by calling B's URL. 2019-05-10 22:50:34,980 WARN > [org.apereo.cas.web.flow.resolver.impl.InitialAuthenticationAttemptWebflowEventResolver] > > - > java.lang.NullPointerException: null >

[cas-user] Re: > 5.3.4 AUP Webflow seem to break createTicketGrantingTicket

Hi Curtis, With CAS 5.3.7 and 5.3.8-SNAPSHOT I am experiencing IllegalArgumentExecepitons due to a bug I discovered. I was able to fix it and created a pull request: https://github.com/apereo/cas/pull/3726 Does that solve your initial issue as well? Cheers, Martin -- - Website: https://aper

[cas-user] Re: > 5.3.4 AUP Webflow seem to break createTicketGrantingTicket

I experienced the exact same issue with my dev environment running on CAS 5.3.5. Unfortunately, I'm far less capable of digging deeper into it than you. I'd recommend to open an issue on Github. -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Gu

[cas-user] Transform String profile attribute to Array when querying the attribute repository

Hi, I'm using a JDBC-based attribute repository to resolve attributes in single-row style . The groups a user is a member of are returned from the database as a comma-seperated list, i.e. the attribute is a s

[cas-user] Re: CAS 5.2.7 - inline groovy attributes

Experienced the same behavior with CAS 5.2. This is what did the trick: "fullName" : "groovy { return attributes['firstName'][0] + ' ' + attributes['lastName'][0] }" Code hier eingeben... -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guideline

[cas-user] Serialization error in ticket granting / encoding - CAS 5.3.5

All, I am using the JDBC Attribute Repository to query a Postgresql database. Amongst others, the query returns two columns that represent arrays, which are transformed into the PgArray class

[cas-user] Re: Limit set of users allowed to login via Facebook / CAS 5.3.5

Hi Andy, Took a while for me to dive deeper into it. In the end, approach 1 seems to be the way to go for me. I haven't though about using the service access strategy. So, thanks a lot for the pointer. Actually, the default strategy seems to be sufficient already. I am thinking of using the re

[cas-user] Re: Limit set of users allowed to login via Facebook / CAS 5.3.5

A 4th approach came to my mind: - 4. Implementing a MFA with the first factor being the regular pac4j/OAuth delegated auth and the second factor the automated database check if the user is "known". That seems a bit over-engineered to me. What do you think? -- - Website: https:

[cas-user] Limit set of users allowed to login via Facebook / CAS 5.3.5

Hi, I've set up CAS 5.3.5 to delegate authn via pac4j/OAuth to Facebook and the like. It works fine, but enables every Facebook user to login. How would I be able to restrict this to "known" Facebook users that I keep a list of, e.g. in a database? I can think of several approaches to achieve