I have a lead on what the issue was related to - I had a setup with the
CascadingPersonAttributeDao. Both the original production issue, and the
tested behavior was observed under this attribute DAO.
In testing, I have swapped out the AttributeDao with the
MergingPersonAttributeDao, using a NoncollidingAttributeAddr merge
strategy. I have not observed the same issue I found earlier in my tests
since (across ~50k logins). While I still have not been able to re-create
the original bug observed, the CascadingPersonAttributeDao seems suspect of
a non-deterministic condition. I am unable to re-trigger the bug found
during testing in which a single user was locked out under the new merge
strategy.
I'm not sure how to reproduce this issue reliably, but I can give some
details about my attribute resolution if it helps: I wanted to merge the
user query from the DB with a static mapping to keep track of what method
they had to login (via ldap, or jdbc, or similar) to determine a user type.
I was merging a NamedStubPersonAttributeDao (listed first) with
a SingleRowJdbcPersonAttributeDao. The CascadingPersonAttributeDao
supported the ReplacingAttributeAdder merge strategy by default (which is
what I wanted), so I went with that strategy.
In my own test case, the test user I was using was *not* in the jdbc
database for attributes - there were no rows returned from the JDBC query,
and so no attributes were added to the static map already defined. Using
the CascadingPersonAttributeDao, it will initially be able to discover the
principal, and log on. After a number of logins, the principal is unable to
be resolved.
Digging into CascadingPersonAttributeDao:
It is <u>highly</u> recommended that the first DAO on the list for this
class is the {@link EchoPersonAttributeDaoImpl} to ensure the seed gets
placed into the general result map.
Since I'm not running with an EchoPersonAttributeDaoImpl, would this
perhaps be the cause of my issue? This isn't hilighted in any of the person
directory readmes at all.
Here's to hoping this is it. I hope this report helps you guys.
-Jeff
On Tuesday, July 19, 2016 at 3:09:59 PM UTC-7, Jeffrey Wong wrote:
>
> After about a month of working perfectly on 4.2.2 deployed to tomcat7,
> running under java8, randomly the in-memory ticketing system would not
> create any more tickets. Restarting the tomcat instance fixed it, but I'm
> wondering why CAS would randomly break on me after working so well! Using a
> LDAP (AD) backed user base with a mysql backed attribute DB. We have pretty
> minimal traffic, so I'm not sure why I am seeing issues after such a small
> amount of time.
>
> Despite having an <AsyncRoot level="error">, no errors have been thrown at
> the time of issue.
>
> Unfortunately, I've only had the org.springframework.jdbc logger set to
> debug, and all others at info, so I have very minimal logging around the
> issue.
>
> I'm noticing both the ldap auth AND the jdbc handlers returning without
> issues (no errors). ...But no tickets?
>
> Here's a sample of the logs:
>
> 2016-07-19 16:28:16,399 INFO
> [org.jasig.cas.authentication.PolicyBasedAuthenticationManager] -
> <LdapAuthenticationHandler successfully authenticated user1>
> 2016-07-19 16:28:16,400 DEBUG [org.springframework.jdbc.core.JdbcTemplate] -
> <Executing prepared SQL query>
> 2016-07-19 16:28:16,400 DEBUG [org.springframework.jdbc.core.JdbcTemplate] -
> <Executing prepared SQL statement[SELECT
> ID,username,FirstName,LastName,Email FROM User WHERE UserName = ?]>
> 2016-07-19 16:28:16,400 DEBUG
> [org.springframework.jdbc.datasource.DataSourceUtils] - <Fetching JDBC
> Connection from DataSource>
> 2016-07-19 16:28:16,401 DEBUG
> [org.springframework.jdbc.datasource.DataSourceUtils] - <Returning JDBC
> Connection to DataSource>
> 2016-07-19 16:28:19,015 INFO
> [org.jasig.cas.authentication.PolicyBasedAuthenticationManager] -
> <LdapAuthenticationHandler successfully authenticated user2>
> 2016-07-19 16:28:19,015 DEBUG [org.springframework.jdbc.core.JdbcTemplate] -
> <Executing prepared SQL query>
> 2016-07-19 16:28:19,015 DEBUG [org.springframework.jdbc.core.JdbcTemplate] -
> <Executing prepared SQL statement[SELECT
> ID,username,FirstName,LastName,Email FROM User WHERE UserName = ?]>
> 2016-07-19 16:28:19,015 DEBUG
> [org.springframework.jdbc.datasource.DataSourceUtils] - <Fetching JDBC
> Connection from DataSource>
> 2016-07-19 16:28:19,017 DEBUG
> [org.springframework.jdbc.datasource.DataSourceUtils] - <Returning JDBC
> Connection to DataSource>
>
> Immediately before this, I've seen tickets that are created (an audit log
> is posted that a ticket granting ticket has been created and validated, and
> all is good). There are no exceptions thrown between when the tickets were
> able to be created and when there was this bottleneck.
>
> On the front end, after the logs say 'success' without a ticket created,
> they are redirected to the main cas login page. Reproducing this is also
> difficult as it will stop intermittently, without warning.
>
> What are the best ways to debug or resolve these sorts of issues? What
> could be causing this issue?
>
> Thanks in advance,
> Jeff
>
--
- CAS gitter chatroom: https://gitter.im/apereo/cas
- CAS mailing list guidelines: https://apereo.github.io/cas/Mailing-Lists.html
- CAS documentation website: https://apereo.github.io/cas
- CAS project website: https://github.com/apereo/cas
---
You received this message because you are subscribed to the Google Groups "CAS
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/a/apereo.org/d/msgid/cas-user/63b2d387-f50f-429d-bf29-1411a0fb1372%40apereo.org.
