Yes, looks fine.
--
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 cas-user+u...@apereo.org.
To post to this group, send email to cas-...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/d2cd5831-3115-402c-83cb-ff193955d3e0%40apereo.org.
It most definitely won’t work, given that’s an invalid property. See:
From: cas-...@apereo.org [mailto:cas-...@apereo.org] On Behalf Of Jeffrey Ramsay
Sent: Tuesday, September 20, 2016 11:28 PM
To: CAS Community <cas-...@apereo.org>
Subject: [cas-user] Re: CAS Management App 5.0.0.RC2-SNAPSHOT
I found the problem and I'm able to access the console.
--
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 cas-user+u...@apereo.org.
To post to this group, send email to cas-...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/bb241356-f071-492e-a274-281f149c3629%40apereo.org.
# User details file location that contains list of users | |
# who are allowed access to the management webapp: | |
# |
# user.details.file.location = classpath:user-details.properties | |
## | |
# JSON Service Registry | |
# | |
# Directory location where JSON service files may be found. | |
# service.registry.config.location=classpath:services | |
It most definitely won’t work, given that’s an invalid property. See:
From: cas-...@apereo.org [mailto:cas-...@apereo.org] On Behalf Of Jeffrey Ramsay
Sent: Tuesday, September 20, 2016 11:28 PM
To: CAS Community <cas-...@apereo.org>
Subject: [cas-user] Re: CAS Management App 5.0.0.RC2-SNAPSHOT
I found the problem and I'm able to access the console.
I tried to override the user-details.properties location by setting the following but it's clearly not working.
# user.details.file.location = classpath:user-details.properties
user.details.file.location=file:/etc/cas/5/dev/user-details.properties
-Jeff
On Sunday, September 18, 2016 at 7:51:13 PM UTC-4, Jeffrey Ramsay wrote:I'm receiving this message "You are not authorized to access this resource. Contact your CAS administrator for more info." while trying to access the CAS management interface. I have tried using the "casuser" account along with my LDAP credentials but both accounts have failed. I tried adding my LDAP userid to the user-details.properties file but that too has been unsuccessful.
Has anyone been able to authenticate using LDAP as user store and the user-default.properties file to limit admin access? I tried the "cas.mgmt" options but that too has not been successful.
-Jeff
--
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 cas-user+unsubscribe@apereo.org.
To post to this group, send email to cas-...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/bb241356-f071-492e-a274-281f149c3629%40apereo.org.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.
--
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 cas-user+unsubscribe@apereo.org.
To post to this group, send email to cas-...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/00b501d2142e%24a4741d90%24ed5c58b0%24%40unicon.net.
You’re perfectly right. Created https://github.com/apereo/cas-services-management-overlay/issues/4
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
To post to this group, send email to cas-...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/bb241356-f071-492e-a274-281f149c3629%40apereo.org.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.
--
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 cas-user+u...@apereo.org.
To post to this group, send email to cas-...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
...
Hi,
We recently encountered an interesting issue with our CAS Implementation, in a few rare cases we have had some users report when logging into a client application (Canvas) they were logged in as another user In brief User A attempts to login with auto saved password and user B was also logging in around same time as user A. When user A is logged in they see Users B information.
After taking a look at the audit logs we noticed that when User A was logging in there was no Login entry they were given a Service ticket with their IP and user B username as if they had already authenticated. User B we did see the login authentication and ST and TGT ticket created under their IP, but we later saw that the TGT was destroyed under user A ip. Also looking in the access logs I found that for this particular case the 2 users had the same JSESSIONID.
So my question would be what might cause this to happen? Could the fact that they had the same jsessionid cause the use to login as the other user?
Hi,
We are running CAS 3.6 with tomcat 8 and in some instances when 2 users are logging in user A is logged in as User B on the client application. So the session information for the first user ends up being used.
We noticed that in the tomcat access logs both users shared the same Jsessionid. It appears that a unique Jsessionid was not generated for the second user when they arrived on the login page.
Has anyone encountered a similar issue? If so any suggestions.
Thanks!
I don't know if that is the problem here, but, it is a great cautionary tale of not...
-- Ray Bon Programmer analyst Development Services, University Systems 2507218831 | CLE 019 | rb...@uvic.ca