Re: [cas-dev] _csrf meta tags are blank

[Jérôme LELEU]

Hi,

This kind of tokens are generally checked on POST requests to protect
against CSRF attacks. I don't think they are used currently. Thus, being
blank is not a problem. We should certainly remove these meta tags if we
don't use them. There is already a specific login ticket mechanism for the
login page.

Thanks.
Best regards,
Jérôme


2016-02-04 0:27 GMT+01:00 Travis Schmidt :

> I was lookging into the /statistics/ssosessions page that is part of 4.2.x.  
> I was getting an error when trying to remove a session in the javascript.  
> The error was that headers were trying to be set as part of the request with 
> an empty key value.  Looking into it some it appears that code in top.jsp is 
> not find _csrf_token and _csrf_header_name.  This is the result in page:
>
>
>  
>  
>
>
> Been trying to figure out how to configure this so it is set, but have not 
> had much luck, so I thought I would ask the question out here.
>
>
> Travis
>
> --
> You received this message because you are subscribed to the Google Groups
> "CAS Developer" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cas-dev+unsubscr...@apereo.org.
> Visit this group at https://groups.google.com/a/apereo.org/group/cas-dev/.
>

-- 
You received this message because you are subscribed to the Google Groups "CAS 
Developer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-dev+unsubscr...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-dev/.

Re: [cas-dev] stable cas server build with oauth support

[Jérôme LELEU]

Hi,

OAuth support exists since CAS 3.5. So you can use the latest stable
release: version 4.1.4.

Thanks.
Best regards,
Jérôme


2016-01-24 23:20 GMT+01:00 Kunal Sinha :

> Hello Team,
>
> I am working on integrating CAS server for our authentication services. We
> need oauth 2 support for social logins. I believe 4.2 has all such
> features. We have been picking changes from master but we are looking for
> something stable so that we could work on our integration part. Could you
> please advise what is the released version that we could use for our work?
>
> Kunal
>
> --
> You received this message because you are subscribed to the Google Groups
> "CAS Developer" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cas-dev+unsubscr...@apereo.org.
> Visit this group at https://groups.google.com/a/apereo.org/group/cas-dev/.
>

-- 
You received this message because you are subscribed to the Google Groups "CAS 
Developer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-dev+unsubscr...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-dev/.

Re: [cas-dev] 4.2 GA release planning

[Jérôme LELEU]

+1

2016-03-16 9:03 GMT+01:00 Misagh Moayyed :

> Team,
>
>
>
> Proposing that we cut the 4.2 GA release early next week. (We are actually
> a few days behind schedule per the milestone date). With 3 release
> candidates behind, I think it’s in a good-enough shape to go out. There is
> only one small improvement requested of the 4.2 line, which we can always
> do later in a patch release. The GA release will get us focused back on
> master more frequently.
>
>
>
> Sound reasonable?
>
>
>
> Misagh
>
> --
> You received this message because you are subscribed to the Google Groups
> "CAS Developer" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cas-dev+unsubscr...@apereo.org.
> Visit this group at https://groups.google.com/a/apereo.org/group/cas-dev/.
>

-- 
You received this message because you are subscribed to the Google Groups "CAS 
Developer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-dev+unsubscr...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-dev/.

Re: [cas-dev] Re: Dependency issue for 5.0.0.M3

[Jérôme LELEU]

Hi,

Right, I read too quickly the logs and I thought it was loaded:  It works now...

Thanks.
Best regards,
Jérôme



2016-08-02 8:03 GMT+02:00 Misagh Moayyed <mmoay...@unicon.net>:

> Probably because you’re actually not using the right registry type:
>
> https://apereo.github.io/cas/development/installation/JSON-Service-Management.html
>
>
> --
> Misagh
>
> From: Jérôme LELEU <lel...@gmail.com> <lel...@gmail.com>
> Reply: Jérôme LELEU <lel...@gmail.com> <lel...@gmail.com>
> Date: August 1, 2016 at 9:11:48 PM
> To: Misagh Moayyed <mmoay...@unicon.net> <mmoay...@unicon.net>
> Cc: CAS Developer <cas-dev@apereo.org> <cas-dev@apereo.org>
> Subject:  Re: [cas-dev] Re: Dependency issue for 5.0.0.M3
>
> Hi,
>
> I finally managed to start the RC1. Though, I have a new issue: it seems
> all CAS services are not authorized despite the appropriate services JSON
> configuration.
>
> Thanks.
> Best regards,
> Jérôme
>
>
> 2016-08-01 18:09 GMT+02:00 Misagh Moayyed <mmoay...@unicon.net>:
>
>> This is done now.
>>
>> --
>> Misagh
>>
>> From: Misagh Moayyed <mmoay...@unicon.net> <mmoay...@unicon.net>
>> Reply: Misagh Moayyed <mmoay...@unicon.net> <mmoay...@unicon.net>
>> Date: August 1, 2016 at 7:05:41 AM
>> To: CAS Developer <cas-dev@apereo.org> <cas-dev@apereo.org>
>> Subject:  Re: [cas-dev] Re: Dependency issue for 5.0.0.M3
>>
>> Jérôme, following up on our conversation ran some tests on RC1 SNAPSHOT
>> and it turns out, when travis publishes snapshots it skips to bootify the
>> CAS application context. I’ll massage the build a bit to let it do that and
>> then you should be set both with snapshots and official releases.
>>
>> Thanks for catching this.
>>
>> --
>> Misagh
>>
>> From: Misagh Moayyed <mmoay...@unicon.net> <mmoay...@unicon.net>
>> Reply: Misagh Moayyed <mmoay...@unicon.net> <mmoay...@unicon.net>
>> Date: August 1, 2016 at 3:14:20 AM
>> To: CAS Developer <cas-dev@apereo.org> <cas-dev@apereo.org>
>> Subject:  Re: [cas-dev] Re: Dependency issue for 5.0.0.M3
>>
>> You want to make sure your pom matches this tree:
>> https://github.com/apereo/cas-overlay-template/tree/5.0
>>
>> If you want to jump on Gitter, we can chat there in real time in the CAS
>> room.
>>
>> --
>> Misagh
>>
>> From: Jérôme LELEU <lel...@gmail.com> <lel...@gmail.com>
>> Reply: Jérôme LELEU <lel...@gmail.com> <lel...@gmail.com>
>> Date: August 1, 2016 at 3:03:31 AM
>> To: Misagh Moayyed <mmoay...@unicon.net> <mmoay...@unicon.net>
>> Cc: CAS Developer <cas-dev@apereo.org> <cas-dev@apereo.org>
>> Subject:  Re: [cas-dev] Re: Dependency issue for 5.0.0.M3
>>
>> Hi,
>>
>> I guess so. Here is my configuration:
>>
>> 
>>5.0.0.M3
>>1.8
>> 
>>
>> 
>>
>>   org.apereo.cas
>>   cas-server-webapp
>>   ${cas.version}
>>   war
>>
>>
>>   org.apereo.cas
>>   cas-server-support-rest
>>   ${cas.version}
>>
>>
>>   org.apereo.cas
>>   cas-server-support-oauth
>>   ${cas.version}
>>
>> 
>>
>> 
>>
>>   
>>  org.apache.maven.plugins
>>  maven-war-plugin
>>  2.6
>>  
>> cas
>> false
>> false
>> 
>>false
>>
>>        
>> org.apereo.cas.web.CasWebApplication
>>
>> org.springframework.boot.loader.WarLauncher
>>
>> 
>> 
>>
>>   org.apereo.cas
>>   cas-server-webapp
>>
>> 
>>  
>>   
>>   
>>  org.apache.maven.plugins
>>  maven-compiler-plugin
>>  3.5.1
>>  
>> ${java.version}
>>     ${java.version}
>>  
>>   
>>
>>cas
>> 
>>
>>
>> Thanks.
>> Best regards,
>> Jérôme
>>
>>
>> 2016-08-01 11:22 GMT+02:00 Misagh Moayyed <mmoay...@unicon.net>:
>>
>>> Are you running this via the overlay?
>>>
>>> --
>&g

Re: [cas-dev] CAS 5 RC2 proposal

[Jérôme LELEU]

Hi,

-0

I still have: https://github.com/apereo/cas/issues/1976 to do and I've
encountered issues with token authentication support and error handling in
case of authentication delegation.

Thanks.
Best regards,
Jérôme


2016-09-09 20:06 GMT+02:00 Dmitriy Kopylenko :

> +1 for RC2 and any follow up release candidate releases to make the GA as
> stable as possible. I am personally not too concerned about not making the
> originally planned date for GA…
>
> D.
>
> On Sep 9, 2016, at 2:03 PM, Misagh Moayyed  wrote:
>
> Hallo,
>
> Given our original schedule for 5 plans to cut a GA around end of
> September, I’d like to propose that we cut RC2 by end of next week, give it
> about 2 weeks and the officially cut the GA per schedule. RC2 isn’t that
> big of a deal, and mostly contains some minor fixed related to SAML2 and
> SLO.
>
> Make sense?
>
> We could just ship with the GA without the second RC too. Slightly less
> confident, but all and all, no biggie.
>
> --
> Misagh
>
> --
> You received this message because you are subscribed to the Google Groups
> "CAS Developer" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cas-dev+unsubscr...@apereo.org.
> Visit this group at https://groups.google.com/a/apereo.org/group/cas-dev/.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "CAS Developer" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cas-dev+unsubscr...@apereo.org.
> Visit this group at https://groups.google.com/a/apereo.org/group/cas-dev/.
>

-- 
You received this message because you are subscribed to the Google Groups "CAS 
Developer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-dev+unsubscr...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-dev/.

[cas-dev] [cas-announce] Java CAS client v3.6.0

[Jérôme LELEU]

The Java CAS client v3.6.0 is released:
https://github.com/apereo/java-cas-client/releases/tag/cas-client-3.6.0

-- 
You received this message because you are subscribed to the Google Groups "CAS 
Developer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-dev+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAP279LzbYTsXR%2BtHhRt%2BywaORB3sT%2B43is4U6_%2BcVnaA4mjg7A%40mail.gmail.com.

[cas-dev] Release Announcement: CAS Security Patches

[Jérôme LELEU]

Hi,

Please see: https://apereo.github.io/2020/10/14/gauthvuln/
Thanks.
Best regards,
Jérôme

-- 
You received this message because you are subscribed to the Google Groups "CAS 
Developer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-dev+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAP279Lw1zqtJP90kD-6ibeFCf4qJMZvLSjsWOBicp11cA9EchQ%40mail.gmail.com.

Re: [cas-dev] CAS 4.0.0: Will it support OIDC (OpenID Connect) features

[Jérôme LELEU]

Hi,

pac4j v1.7.0 is an old version based on an old version of the Nimbus SDK
without default support for Keycloak.

So, even if it is feasible, you'll need customisations to make it work.

As I said on the pac4j mailing list, I highly recommend upgrading the CAS
server.

Thanks.
Best regards,
Jérôme


Le lun. 28 sept. 2020 à 19:47, yarra srinivas  a
écrit :

> Hi Folks,
>
> We' re using pretty older version of CAS component (i.e. 4.0.0) for
> authentication purpose. As per requirement, we don't want to upgrade the
> CAS Server component; If possible delegate the authentication to third
> party component like Keycloak. So, to avoid the CAS component upgrade and
> it's inter-dependency components like spring and other modules in the
> project.
>
> My basic a doubts as:
>
> 1. Will it possible with CAS 4.0.0 to delegate authentication to Keycloak
> Server?
> 2. if so, what will be best robust delegate the authentication techniques
> based on CAS 4.0.0 help us to connect to Keycloak component.
>
>
> Thanks,
> Yarra
>
> --
> You received this message because you are subscribed to the Google Groups
> "CAS Developer" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cas-dev+unsubscr...@apereo.org.
> To view this discussion on the web visit
> https://groups.google.com/a/apereo.org/d/msgid/cas-dev/24bda63e-781f-4bee-ba0d-8b2bb01f2d80n%40apereo.org
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups "CAS 
Developer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-dev+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAP279LyFB6CBeZ_ta%3D5p4Y6PjuAQCj_ZvcZSCbkS0_PYFfBZxQ%40mail.gmail.com.

[cas-dev] Re: [cas-announce] Apereo Paris 21 & ESUP-Days 31

[Jérôme LELEU]

And you'll talk about CAS at 11h20 ;-)

Le mar. 2 févr. 2021 à 07:42, Misagh  a écrit :

> The ESUP-Portail Consortium and the Apereo Foundation are pleased to
> invite you to the eighth edition of the ESUP-Days/Apereo Paris event
> that will take place on February 2, 2021. Due to the pandemic
> situation, we have no other choice but to go fully online for this
> edition. The "good" thing about this is that it will make it far
> easier for people outside of France to participate. You don't speak
> the "language of Molière" fluently? No worries! There will be
> simultaneous translation so you can appreciate all the sessions no
> matter which language is being used.
>
> Check out the program here:
> https://www.esup-portail.org/conference/index-EN.html
>
> --
> You received this message because you are subscribed to the Google Groups
> "CAS Announcements" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cas-announce+unsubscr...@apereo.org.
> To view this discussion on the web visit
> https://groups.google.com/a/apereo.org/d/msgid/cas-announce/CAGSBKkcfvygEoP6MmYvmvn2%3Dz6mGcxYm7BqwXi8-EByC-EVi_w%40mail.gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups "CAS 
Developer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-dev+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAP279LzcwF0nnNG_Aos-agGGOCQJ8zZBrNRPn8yd5Gs4vBqVMw%40mail.gmail.com.

Re: [cas-dev] Better protocol differentiation

[Jérôme LELEU]

Hi,

1. I just tested it again with 6.4.0-RC5 and I still have the issue.

On the client side, I use the pac4j demo:
https://github.com/pac4j/spring-webmvc-pac4j-boot-demo on port 8081 (HTTP)
: server.port=8081 in the *application.properties*
On the server side, I use a CAS demo:
https://github.com/casinthecloud/cas-overlay-demo on port 8080 (HTTP) run
by a Tomcat 9.
I have the SAML IdP dependency:


org.apereo.cas
cas-server-support-saml-idp
${cas.version}


and this JSON definition:

{
  "@class" : "org.apereo.cas.support.saml.services.SamlRegisteredService",
  "serviceId" : "http://localhost:8081.*;,
  "name" : "SAMLService",
  "id" : 1,
  "evaluationOrder" : 1,
  "metadataLocation" :
"/Users/jleleu/sources/spring-webmvc-pac4j-boot-demo/sp-metadata.xml"
}

>From the client demo, I can log in via SAML or via CAS with the following
URL:
http://localhost:8080/cas/login?service=http%3A%2F%2Flocalhost%3A8081%2Fcallback%3Fclient_name%3DCasClient

With which version did you test it?

2. This is what I feared: breaking the world. I understand the rationale.
Let's solve #1 first.

Thanks.
Best regards,
Jérôme


Le ven. 11 juin 2021 à 09:54, Misagh  a écrit :

> I suppose there are two things to review:
>
> 1. The case you are describing actually works OK for me. If I have a
> SAML SP and I try to prevent it's a CAS SP, I correctly get
> "application unauthorized". So either something is missing in your
> setup, or I am overlooking something. Of course "it works for me"
> means nothing. You should likely start with a test case that tries to
> reproduce this, with puppeteer specially so we can see where the
> problem is. Either way, the @class attribute indicates the allowed
> protocol. We shouldn't need to make any other adjustments.
>
> 2. For the more general case, I have often thought about going down
> the same route as you suggest, to break up CAS SPs into their own
> entity and make the regex service some sort of parent abstract entity.
> Initial research shows that this is tons of work [never to be
> seriously funded by anyone], with potential to break the world with
> minor benefits which do not make this worthwhile. If this were to be
> done, v7 would be a good target but I would need to be 300% sure this
> is necessary, and cannot be fixed/improved in any other "easy" way,
> and that it should start with a concrete use case or problem that can
> be produced in #1.
>
> On Fri, Jun 11, 2021 at 10:42 AM Jérôme LELEU  wrote:
> >
> > Hi,
> >
> > Thanks for the feedback.
> >
> > @Misagh: do you have any plan on this?
> >
> > Best regards,
> > Jérôme
> >
> >
> > Le lun. 7 juin 2021 à 17:41, Daniel Ellentuck  a
> écrit :
> >>
> >> Hi Jerome, et. al.,
> >>
> >> I agree, and that would be a nice first step.  I wound up adding code
> in which a given registered service is only authorized for use with a
> specific list of protocols, and an attempt to access the registered service
> (e.g., by findServiceBy(Service)) for an unauthorized protocol returns null.
> >>
> >> Dan
> >>
> >> Dan Ellentuck
> >> Columbia University I.T.
> >>
> >>
> >> On Mon, Jun 7, 2021 at 4:07 AM Jérôme LELEU  wrote:
> >>>
> >>> Hi,
> >>>
> >>> I have this SAML SP definition in CAS:
> >>>
> >>> {
> >>>   "@class" :
> "org.apereo.cas.support.saml.services.SamlRegisteredService",
> >>>   "serviceId" : "http://localhost:8081.*;,
> >>>   "name" : "SAMLService",
> >>>   "id" : 1,
> >>>   "evaluationOrder" : 1,
> >>>   "metadataLocation" :
> "/Users/jleleu/sources/spring-webmvc-pac4j-boot-demo/sp-metadata.xml"
> >>> }
> >>>
> >>>
> >>> And I have realized that I can log in using the CAS protocol with the
> same service definition :
> >>>
> >>>
> http://localhost:8080/cas/login?service=http%3A%2F%2Flocalhost%3A8081%2Fcallback%3Fclient_name%3DCasClient
> >>>
> >>> I would have expected the SAML definition not to work for the CAS
> protocol.
> >>>
> >>> More generally, I have the feeling that protocols are not sufficiently
> differentiated in CAS.
> >>> I'm thinking about the SamlIdPSingleLogoutServiceMessageHandler and
> the DefaultSingleLogoutServiceMessageHandler components although there
> might be better examples.
> >>>
> >>> We have

Re: [cas-dev] Better protocol differentiation

[Jérôme LELEU]

Hi,

No, it's fixed with the latest snapshot.
Thanks.
Best regards,
Jérôme


Le ven. 18 juin 2021 à 09:43, Misagh  a écrit :

> I might have been a few steps ahead of you. Are you still seeing this
> with the latest snapshots?
>
> On Mon, Jun 14, 2021 at 8:09 PM Jérôme LELEU  wrote:
> >
> > Hi,
> >
> > 1. I just tested it again with 6.4.0-RC5 and I still have the issue.
> >
> > On the client side, I use the pac4j demo:
> https://github.com/pac4j/spring-webmvc-pac4j-boot-demo on port 8081
> (HTTP) : server.port=8081 in the application.properties
> > On the server side, I use a CAS demo:
> https://github.com/casinthecloud/cas-overlay-demo on port 8080 (HTTP) run
> by a Tomcat 9.
> > I have the SAML IdP dependency:
> >
> > 
> > org.apereo.cas
> > cas-server-support-saml-idp
> > ${cas.version}
> > 
> >
> > and this JSON definition:
> >
> > {
> >   "@class" :
> "org.apereo.cas.support.saml.services.SamlRegisteredService",
> >   "serviceId" : "http://localhost:8081.*;,
> >   "name" : "SAMLService",
> >   "id" : 1,
> >   "evaluationOrder" : 1,
> >   "metadataLocation" :
> "/Users/jleleu/sources/spring-webmvc-pac4j-boot-demo/sp-metadata.xml"
> > }
> >
> > From the client demo, I can log in via SAML or via CAS with the
> following URL:
> http://localhost:8080/cas/login?service=http%3A%2F%2Flocalhost%3A8081%2Fcallback%3Fclient_name%3DCasClient
> >
> > With which version did you test it?
> >
> > 2. This is what I feared: breaking the world. I understand the rationale.
> > Let's solve #1 first.
> >
> > Thanks.
> > Best regards,
> > Jérôme
>
> --
> You received this message because you are subscribed to the Google Groups
> "CAS Developer" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cas-dev+unsubscr...@apereo.org.
> To view this discussion on the web visit
> https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAGSBKkfQ4rGZ7QCUCFf_%3DpWTP3pdQbuvXVo%2B0qgzABtP%2B%3DwJbg%40mail.gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups "CAS 
Developer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-dev+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAP279Ly2C%2BjuNjgg7LLK9i72uNsBZ4O0aRSYUXUFvX7GxG-%2Bxg%40mail.gmail.com.

Re: [cas-dev] Better protocol differentiation

[Jérôme LELEU]

Hi,

Thanks for the feedback.

@Misagh: do you have any plan on this?

Best regards,
Jérôme


Le lun. 7 juin 2021 à 17:41, Daniel Ellentuck  a écrit :

> Hi Jerome, et. al.,
>
> I agree, and that would be a nice first step.  I wound up adding code in
> which a given registered service is only authorized for use with a specific
> list of protocols, and an attempt to access the registered service (e.g.,
> by findServiceBy(Service)) for an unauthorized protocol returns null.
>
> Dan
>
> Dan Ellentuck
> Columbia University I.T.
>
>
> On Mon, Jun 7, 2021 at 4:07 AM Jérôme LELEU  wrote:
>
>> Hi,
>>
>> I have this SAML SP definition in CAS:
>>
>> {
>>   "@class" : "org.apereo.cas.support.saml.services.SamlRegisteredService",
>>   "serviceId" : "http://localhost:8081.*; 
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A8081.-2A-2522=DwQFaQ=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE=-mB15dnBKNLdHrR8X3_Clw=MMq2PDYGP2WsYd3mmC_2FG6n4utfcneLwsfVeGJAKVw=KQ8qDkmI7UpPoBJqooKSXoX1ZED8H9UHUgtNp-NBjmo=>,
>>   "name" : "SAMLService",
>>   "id" : 1,
>>   "evaluationOrder" : 1,
>>   "metadataLocation" : 
>> "/Users/jleleu/sources/spring-webmvc-pac4j-boot-demo/sp-metadata.xml"
>> }
>>
>>
>> And I have realized that I can log in using the CAS protocol with the
>> same service definition :
>>
>>
>> http://localhost:8080/cas/login?service=http%3A%2F%2Flocalhost%3A8081%2Fcallback%3Fclient_name%3DCasClient
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A8080_cas_login-3Fservice-3Dhttp-253A-252F-252Flocalhost-253A8081-252Fcallback-253Fclient-5Fname-253DCasClient=DwMFaQ=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE=-mB15dnBKNLdHrR8X3_Clw=MMq2PDYGP2WsYd3mmC_2FG6n4utfcneLwsfVeGJAKVw=mapZS2wG2rZ3Hf2l_3QsYCKkRBtQisWhAMRhowYTwds=>
>>
>> I would have expected the SAML definition not to work for the CAS
>> protocol.
>>
>> More generally, I have the feeling that protocols are not sufficiently
>> differentiated in CAS.
>> I'm thinking about the SamlIdPSingleLogoutServiceMessageHandler and the
>> DefaultSingleLogoutServiceMessageHandler components although there might
>> be better examples.
>>
>> We have built the SAML, OAuth and OIDC protocols on top of the CAS
>> protocol while CAS should be somehow alongside the other protocols.
>>
>> In terms of design, as a first step, I would make RegexRegisteredService an
>> abstract class and create a *CasRegisteredService* (inheriting from it)
>> like we have a SamlRegisteredService, a OAuthRegisteredService...
>>
>> This may be a huge change better targeted at v6.5 or even v7.
>>
>> Does it make sense?
>>
>> Thanks.
>> Best regards,
>> Jérôme
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "CAS Developer" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to cas-dev+unsubscr...@apereo.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAP279LzNmaCyk1f_ugJRcQbTappYN8zkKZnw6YAfYdyJZpK7HA%40mail.gmail.com
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_a_apereo.org_d_msgid_cas-2Ddev_CAP279LzNmaCyk1f-5FugJRcQbTappYN8zkKZnw6YAfYdyJZpK7HA-2540mail.gmail.com-3Futm-5Fmedium-3Demail-26utm-5Fsource-3Dfooter=DwMFaQ=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE=-mB15dnBKNLdHrR8X3_Clw=MMq2PDYGP2WsYd3mmC_2FG6n4utfcneLwsfVeGJAKVw=P-KbBR7VRxjIr5e8vpi_BrdkJyjXcA-mDvmdXdFcaYs=>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups "CAS 
Developer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-dev+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAP279LwwkU8Y9%2BJ_JbJQMAt%2Be5VoPnXxUkH%2B_e1rzs%2BbEj8Adw%40mail.gmail.com.

[cas-dev] Different versions in BOM vs WAR

[Jérôme LELEU]

Hi,

I notice that the versions in the BOM are sometimes different from the
versions in the WAR.

For example, in version 6.4.0-RC5, there is:
- guava 30.0-jre in the BOM
- guava 30.1.1-jre in the WAR.

Shouldn't both versions be the same?

Thanks.
Best regards,
Jérôme

-- 
You received this message because you are subscribed to the Google Groups "CAS 
Developer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-dev+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAP279Lyit7KSxekntCjbmHv3pTMNyjgawQky6C9z0%3DyC_zzMLg%40mail.gmail.com.

Re: [cas-dev] Different versions in BOM vs WAR

[Jérôme LELEU]

OK. Thank you for the explanations

Le ven. 2 juil. 2021 à 15:41, Misagh  a écrit :

> Sorry, I should have been more clear. You should first:
>
> - search from which CAS dependency this version 30.1.1-jre comes from
> and exclude it in the dependencies.gradle file.
> - Then, optionally, upgrade guava to the latest.
>
> On Fri, Jul 2, 2021 at 5:38 PM Jérôme LELEU  wrote:
> >
> > Sorry but I'm not sure to follow you.
> >
> > Let's take my guava example on master.
> >
> > In the gradle.properties, I see: guavaVersion=30.0-jre
> >
> > In the WEB-INF/lib directory of the cas-server-webapp WAR, I see:
> > guava-2.9.0.jar
> > guava-30.0-jre.jar
> > guava-30.1.1-jre.jar
> > jackson-datatype-guava-2.12.3.jar
> > listenablefuture-.0-empty-to-avoid-conflict-with-guava.jar
> >
> > What should I do? Update the gradle.properties file to version
> 30.1.1-jre for guava or search from which CAS dependency this version
> 30.1.1-jre comes from and exclude it in the dependencies.gradle file?
> >
> > Thanks.
> > Best regards,
> > Jérôme
> >
> >
> > Le ven. 2 juil. 2021 à 14:52, Misagh  a écrit
> :
> >>
> >> Only when you introduce your own dependencies. Otherwise, it needs to
> >> be fixed at the source where you have to look for the source of
> >> conflict.
> >>
> >> On Fri, Jul 2, 2021 at 4:51 PM Jérôme LELEU  wrote:
> >> >
> >> > Hi,
> >> >
> >> > Thanks for the feedback.
> >> > So this is something we must do manually when needed.
> >> > Best regards,
> >> > Jérôme
> >> >
> >> >
> >> > Le ven. 2 juil. 2021 à 14:33, Misagh  a
> écrit :
> >> >>
> >> >> The latter. You'd have to see where the conflict comes from first.
> >> >>
> >> >> On Fri, Jul 2, 2021 at 4:31 PM Jérôme LELEU 
> wrote:
> >> >> >
> >> >> > Hi,
> >> >> >
> >> >> > OK. I agree.
> >> >> > So what's the fix? Changing the BOM generation process or changing
> the dependency versions in the gradle.properties?
> >> >> > Thanks.
> >> >> > Best regards,
> >> >> > Jérôme
> >> >> >
> >> >> >
> >> >> > Le ven. 2 juil. 2021 à 11:11, Misagh  a
> écrit :
> >> >> >>
> >> >> >> They should.
> >> >> >>
> >> >> >> On Fri, Jul 2, 2021 at 1:10 PM Jérôme LELEU 
> wrote:
> >> >> >> >
> >> >> >> > Hi,
> >> >> >> >
> >> >> >> > I notice that the versions in the BOM are sometimes different
> from the versions in the WAR.
> >> >> >> >
> >> >> >> > For example, in version 6.4.0-RC5, there is:
> >> >> >> > - guava 30.0-jre in the BOM
> >> >> >> > - guava 30.1.1-jre in the WAR.
> >> >> >> >
> >> >> >> > Shouldn't both versions be the same?
> >> >> >> >
> >> >> >> > Thanks.
> >> >> >> > Best regards,
> >> >> >> > Jérôme
> >> >> >> >
> >> >> >> > --
> >> >> >> > You received this message because you are subscribed to the
> Google Groups "CAS Developer" group.
> >> >> >> > To unsubscribe from this group and stop receiving emails from
> it, send an email to cas-dev+unsubscr...@apereo.org.
> >> >> >> > To view this discussion on the web visit
> https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAP279Lyit7KSxekntCjbmHv3pTMNyjgawQky6C9z0%3DyC_zzMLg%40mail.gmail.com
> .
> >> >> >>
> >> >> >> --
> >> >> >> You received this message because you are subscribed to the
> Google Groups "CAS Developer" group.
> >> >> >> To unsubscribe from this group and stop receiving emails from it,
> send an email to cas-dev+unsubscr...@apereo.org.
> >> >> >> To view this discussion on the web visit
> https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAGSBKkd7xjeGs9GeEVB40MFm0JcUWhTcCXbokk6hQJZTZWqurA%40mail.gmail.com
> .
> >> >>
> >> >> --
> >> >> You received this message because you are subscribed to the Google
> Groups "CAS Developer" group.
> >> >> To unsubscribe from this group and stop receiving emails from it,
> send an email to cas-dev+unsubscr...@apereo.org.
> >> >> To view this discussion on the web visit
> https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAGSBKkfhAfiWqj4yWArbDqfXDo4SY8CnD57tG4ki%2BLPN0X0U%3Dg%40mail.gmail.com
> .
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups "CAS Developer" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an email to cas-dev+unsubscr...@apereo.org.
> >> To view this discussion on the web visit
> https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAGSBKkdfkx0f_vZ8cS3gY9drj1cfGF7%3DW8ki4MRW3h2Fqjrs%3DA%40mail.gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups "CAS 
Developer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-dev+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAP279LwOxkafS6E2NbM%3D1NjRUVTrRHwM5Le%2Bbf-2ppGd3bHo2A%40mail.gmail.com.

Re: [cas-dev] Different versions in BOM vs WAR

[Jérôme LELEU]

Hi,

OK. I agree.
So what's the fix? Changing the BOM generation process or changing the
dependency versions in the gradle.properties?
Thanks.
Best regards,
Jérôme


Le ven. 2 juil. 2021 à 11:11, Misagh  a écrit :

> They should.
>
> On Fri, Jul 2, 2021 at 1:10 PM Jérôme LELEU  wrote:
> >
> > Hi,
> >
> > I notice that the versions in the BOM are sometimes different from the
> versions in the WAR.
> >
> > For example, in version 6.4.0-RC5, there is:
> > - guava 30.0-jre in the BOM
> > - guava 30.1.1-jre in the WAR.
> >
> > Shouldn't both versions be the same?
> >
> > Thanks.
> > Best regards,
> > Jérôme
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "CAS Developer" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to cas-dev+unsubscr...@apereo.org.
> > To view this discussion on the web visit
> https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAP279Lyit7KSxekntCjbmHv3pTMNyjgawQky6C9z0%3DyC_zzMLg%40mail.gmail.com
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "CAS Developer" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cas-dev+unsubscr...@apereo.org.
> To view this discussion on the web visit
> https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAGSBKkd7xjeGs9GeEVB40MFm0JcUWhTcCXbokk6hQJZTZWqurA%40mail.gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups "CAS 
Developer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-dev+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAP279LykOzMn8_m3urxP%3DrssVUYUnA%2BcsHXWjNBN3pcDivg16g%40mail.gmail.com.

Re: [cas-dev] Different versions in BOM vs WAR

[Jérôme LELEU]

Sorry but I'm not sure to follow you.

Let's take my guava example on master.

In the *gradle.properties*, I see: guavaVersion=30.0-jre

In the *WEB-INF/lib* directory of the *cas-server-webapp* WAR, I see:
guava-2.9.0.jar
guava-30.0-jre.jar
*guava-30.1.1-jre.jar*
jackson-datatype-guava-2.12.3.jar
listenablefuture-.0-empty-to-avoid-conflict-with-guava.jar

What should I do? Update the *gradle.properties* file to version 30.1.1-jre
for guava or search from which CAS dependency this version 30.1.1-jre comes
from and exclude it in the *dependencies.gradle* file?

Thanks.
Best regards,
Jérôme


Le ven. 2 juil. 2021 à 14:52, Misagh  a écrit :

> Only when you introduce your own dependencies. Otherwise, it needs to
> be fixed at the source where you have to look for the source of
> conflict.
>
> On Fri, Jul 2, 2021 at 4:51 PM Jérôme LELEU  wrote:
> >
> > Hi,
> >
> > Thanks for the feedback.
> > So this is something we must do manually when needed.
> > Best regards,
> > Jérôme
> >
> >
> > Le ven. 2 juil. 2021 à 14:33, Misagh  a écrit
> :
> >>
> >> The latter. You'd have to see where the conflict comes from first.
> >>
> >> On Fri, Jul 2, 2021 at 4:31 PM Jérôme LELEU  wrote:
> >> >
> >> > Hi,
> >> >
> >> > OK. I agree.
> >> > So what's the fix? Changing the BOM generation process or changing
> the dependency versions in the gradle.properties?
> >> > Thanks.
> >> > Best regards,
> >> > Jérôme
> >> >
> >> >
> >> > Le ven. 2 juil. 2021 à 11:11, Misagh  a
> écrit :
> >> >>
> >> >> They should.
> >> >>
> >> >> On Fri, Jul 2, 2021 at 1:10 PM Jérôme LELEU 
> wrote:
> >> >> >
> >> >> > Hi,
> >> >> >
> >> >> > I notice that the versions in the BOM are sometimes different from
> the versions in the WAR.
> >> >> >
> >> >> > For example, in version 6.4.0-RC5, there is:
> >> >> > - guava 30.0-jre in the BOM
> >> >> > - guava 30.1.1-jre in the WAR.
> >> >> >
> >> >> > Shouldn't both versions be the same?
> >> >> >
> >> >> > Thanks.
> >> >> > Best regards,
> >> >> > Jérôme
> >> >> >
> >> >> > --
> >> >> > You received this message because you are subscribed to the Google
> Groups "CAS Developer" group.
> >> >> > To unsubscribe from this group and stop receiving emails from it,
> send an email to cas-dev+unsubscr...@apereo.org.
> >> >> > To view this discussion on the web visit
> https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAP279Lyit7KSxekntCjbmHv3pTMNyjgawQky6C9z0%3DyC_zzMLg%40mail.gmail.com
> .
> >> >>
> >> >> --
> >> >> You received this message because you are subscribed to the Google
> Groups "CAS Developer" group.
> >> >> To unsubscribe from this group and stop receiving emails from it,
> send an email to cas-dev+unsubscr...@apereo.org.
> >> >> To view this discussion on the web visit
> https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAGSBKkd7xjeGs9GeEVB40MFm0JcUWhTcCXbokk6hQJZTZWqurA%40mail.gmail.com
> .
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups "CAS Developer" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an email to cas-dev+unsubscr...@apereo.org.
> >> To view this discussion on the web visit
> https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAGSBKkfhAfiWqj4yWArbDqfXDo4SY8CnD57tG4ki%2BLPN0X0U%3Dg%40mail.gmail.com
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "CAS Developer" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cas-dev+unsubscr...@apereo.org.
> To view this discussion on the web visit
> https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAGSBKkdfkx0f_vZ8cS3gY9drj1cfGF7%3DW8ki4MRW3h2Fqjrs%3DA%40mail.gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups "CAS 
Developer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-dev+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAP279Ly_3%2BYDp5rGWmVbsqmFqrz8FU%2Bih428-zEfXKV%3Df5mVMw%40mail.gmail.com.

Re: [cas-dev] Different versions in BOM vs WAR

[Jérôme LELEU]

Hi,

Thanks for the feedback.
So this is something we must do manually when needed.
Best regards,
Jérôme


Le ven. 2 juil. 2021 à 14:33, Misagh  a écrit :

> The latter. You'd have to see where the conflict comes from first.
>
> On Fri, Jul 2, 2021 at 4:31 PM Jérôme LELEU  wrote:
> >
> > Hi,
> >
> > OK. I agree.
> > So what's the fix? Changing the BOM generation process or changing the
> dependency versions in the gradle.properties?
> > Thanks.
> > Best regards,
> > Jérôme
> >
> >
> > Le ven. 2 juil. 2021 à 11:11, Misagh  a écrit
> :
> >>
> >> They should.
> >>
> >> On Fri, Jul 2, 2021 at 1:10 PM Jérôme LELEU  wrote:
> >> >
> >> > Hi,
> >> >
> >> > I notice that the versions in the BOM are sometimes different from
> the versions in the WAR.
> >> >
> >> > For example, in version 6.4.0-RC5, there is:
> >> > - guava 30.0-jre in the BOM
> >> > - guava 30.1.1-jre in the WAR.
> >> >
> >> > Shouldn't both versions be the same?
> >> >
> >> > Thanks.
> >> > Best regards,
> >> > Jérôme
> >> >
> >> > --
> >> > You received this message because you are subscribed to the Google
> Groups "CAS Developer" group.
> >> > To unsubscribe from this group and stop receiving emails from it,
> send an email to cas-dev+unsubscr...@apereo.org.
> >> > To view this discussion on the web visit
> https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAP279Lyit7KSxekntCjbmHv3pTMNyjgawQky6C9z0%3DyC_zzMLg%40mail.gmail.com
> .
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups "CAS Developer" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an email to cas-dev+unsubscr...@apereo.org.
> >> To view this discussion on the web visit
> https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAGSBKkd7xjeGs9GeEVB40MFm0JcUWhTcCXbokk6hQJZTZWqurA%40mail.gmail.com
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "CAS Developer" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cas-dev+unsubscr...@apereo.org.
> To view this discussion on the web visit
> https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAGSBKkfhAfiWqj4yWArbDqfXDo4SY8CnD57tG4ki%2BLPN0X0U%3Dg%40mail.gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups "CAS 
Developer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-dev+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAP279LybjwBp27iwTuiTMcsHNUDBbGwexCS8E8Bp%3D8GL%3DZa2xg%40mail.gmail.com.

[cas-dev] Re: [cas-user] very slow ticket delivery on CAS 6.6 & redis ticket registry

[Jérôme LELEU]

Hi,

Moving the discussion to the dev mailing list.

I think that using the userId suffix was made to improve performance when
searching for user sessions.
Instead of scanning all existing keys to see if it is a TGT of this user,
the idea was to scan only the tickets made for this user.

About the solutions, I don't think we should remove the userId suffix as we
would lose the previous improvement.
I think that a new cache would make sense to improve performance but I
would store it directly in Redis to make things easier.
In fact, we would have a double keys indexing, maybe something like:
CAS_TICKET_USER:ticketId:userId => (ticket) + CAS_TICKET:ticketId =>
(CAS_TICKET_USER:ticketId:userId)

@Misagh: what do you think of this problem and solutions?

Thanks.
Best regards,
Jérôme


Le ven. 28 oct. 2022 à 14:05, Pascal Rigaux 
a écrit :

> Solutions I can think of:
>
> - add a memory cache [ ticketId => redisKey ]
>(it should help a lot, even if it will still be slower than before in
> case of load balancing)
>
> - revert suffixing redis key with userid
>(easy change in RedisTicketRegistry.java)
>
>- and possibly add userid suffix in a UniqueTicketIdGenerator, the way
> HostNameBasedUniqueTicketIdGenerator suffixes with hostname
>  (but it may be hard to do...)
>
> cu
>
> On 28/10/2022 11:13, Jérôme LELEU wrote:
> > Hi,
> >
> > Thanks for raising the point.
> >
> > It's always hard to find a good balance between a generic design and
> performance.
> >
> > It seems to me that performing scans to get a ticket is not the best
> thing to do in terms of performance.
> >
> > The Redis ticket registry is commonly used and we should try to avoid
> any performance degradation.
> >
> > I have a few ideas in mind, but I'm not a Redis specialist: what do you
> propose?
> >
> > Thanks.
> > Best regards,
> > Jérôme
> >
> >
> > Le jeu. 27 oct. 2022 à 19:59, Pascal Rigaux <
> pascal.rig...@univ-paris1.fr <mailto:pascal.rig...@univ-paris1.fr>> a
> écrit :
> >
> > Hi,
> >
> > In 6.6.x Redis ticket registry key is suffixed with userid (since
> 6.6.0-RC4)
> >
> > This is great to know who owns a TGT or a ST.
> >
> > Alas, this means getting a TGT from Redis now requires a "SCAN"...
> which is much more costly.
> > Example: full "SCAN" is ~100 times slower then "GET" on our
> production Redis (dbsize ~100k, because we have 1 month rememberMe TGT)
> >
> >
> > For the record, getting a ST triggers
> > - on 5.3 : 8 redis "GET" on the TGT
> > - on 6.5 : 17 redis "GET" on the TGT
> > - on 6.6 : 15 redis "SCAN" + "GET" on the TGT on a small redis db
> >
> >
> >
> > PS: "cas.ticket.registry.core.enable-locking=false" fails on redis
> ticket registry with error
> >   > Could not find a destroy method named 'destroy' on bean with
> name 'casTicketRegistryRedisLockRegistry'
>
> --
> - Website: https://apereo.github.io/cas
> - Gitter Chatroom: https://gitter.im/apereo/cas
> - List Guidelines: https://goo.gl/1VRrw7
> - Contributions: https://goo.gl/mh7qDG
> ---
> 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+unsubscr...@apereo.org.
> To view this discussion on the web visit
> https://groups.google.com/a/apereo.org/d/msgid/cas-user/fcfa4754-17f7-384f-7254-e6faad0f4cff%40univ-paris1.fr
> .
>

-- 
You received this message because you are subscribed to the Google Groups "CAS 
Developer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-dev+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAP279Lw22-%2Bc4YRBunkfOErebndGrpQrTK39Dixxpa9CmVqTjg%40mail.gmail.com.

[cas-dev] pac4j v6: development started

[Jérôme LELEU]

Hi,

I just started the development of pac4j v6.

CAS v7 will use pac4j v6.

So the ETA is *February 2023*, just before CAS v7.

It is based on *JDK 17*.

The deprecated *pac4j-saml*, *pac4j-cas* and *pac4j-springboot *modules are
removed.

The *pac4j-saml-opensamlv5* module is renamed as *pac4j-saml*.

The *pac4j-cas-clientv4* module is renamed as *pac4j-cas*.

The *pac4j-springbootv3 *module is renamed as *pac4j-springboot*.

The deprecated *pac4j-javaee* module is kept. Migration to the
*pac4j-jakartaee* module is expected.

Thanks.
Best regards,
Jérôme

-- 
You received this message because you are subscribed to the Google Groups "CAS 
Developer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-dev+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAP279LyAUpqhN%2BQpGPYUJ4OnoHUaxF2UCkSCPAQ2tirm4yj4sw%40mail.gmail.com.

Re: [cas-dev] Re: [cas-user] very slow ticket delivery on CAS 6.6 & redis ticket registry

[Jérôme LELEU]

Hi,

I made a new test with 7.0.0-RC2 in a two node environment with round robin.
Indeed, the average time is 0 ms. Performances are excellent!
Thanks.
Best regards,
Jérôme


Le ven. 18 nov. 2022 à 18:54, Misagh  a écrit :

> very nice!
>
> Could I ask you to also verify master (or v7 RC2) with a clustered
> setup, whenever you find the chance? I was able to make the cache work
> across the cluster, and I think you should see the average time be
> closer to 0.
>
> On Fri, Nov 18, 2022 at 9:33 PM leleuj  wrote:
> >
> > Hi,
> >
> > Some follow up on this master.
> > I have made new performance tests between v6.6.2 and v6.6.3-SNAPSHOT to
> evaluate the backport from v7.
> >
> > For 5000 logins and service ticket validations:
> > 6.6.2 :
> > Average time: 221 ms
> > 6.6.3-SNAPSHOT:
> > Average time: 4 ms
> >
> > Performance are now very good for the incoming 6.6.3 release.
> >
> > Thanks.
> > Best regards,
> > Jérôme
> >
> >
> > Le mardi 15 novembre 2022 à 07:48:36 UTC+1, leleuj a écrit :
> >>
> >> EXCELLENT!
> >>
> >> Le mar. 15 nov. 2022 à 04:54, Misagh  a écrit :
> >>>
> >>>
> >>>
> >>>
> >>> On Mon, Nov 14, 2022, 4:58 PM Jérôme LELEU  wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> I have made new tests.
> >>>>
> >>>> With the new implementation, I have experienced Redis crashes, but
> I'm not sure this is meaningful.
> >>>> In any case, I have updated to Redis v7 with 500Mo of memory.
> >>>
> >>>
> >>> I ran into something similar. I think this is mainly due to the large
> number of operations and tickets and that the redis setup is not exactly
> tuned to handle the load.
> >>>
> >>>>
> >>>>
> >>>> CAS v6.5 :
> >>>> Average time node 1: 1 ms
> >>>> Average time node 2: 1 ms
> >>>>
> >>>> CAS v7.0.0 fix REDIS :
> >>>> Average time node 1: 2 ms
> >>>> Average time node 2: 2 ms
> >>>>
> >>>> While it performs better on CAS v6.5, it now performs very well on
> CAS v7 as well.
> >>>>
> >>>> Did you change something else in addition to the cache?
> >>>
> >>>
> >>> Yes I am experimenting with the ticket pattern lookup to not use
> scanning. This seems to be good enough even without the cache. If you
> disable the cache altogether on a single node by forcing its capacity to be
> at 0, (i.e never cache anything) you should see comparable performance
> numbers. This should fit the scope of 6.6, if we were to backport.
> >>>
> >>> I'd like to keep the cache changes in master and continue testing.
> Cache invalidation can be very tricky here to make sure updates and changes
> to one ticket on one node is correctly found and processed on another.
> Given the current caching model is incredibly fast, I'd like to stick to
> this strategy and work out the other possible issues with clustered setups
> and event sinks. If I cannot make it work reliably, then I would consider
> either removing the cache or changing its structure. It would be slower
> than what it is now, but still very very fast.
> >>>
> >>> And if this technique works ok, it might be something to extend to
> other registry plugins as the need comes up.
> >>>
> >>>
> >>>
> >>>>>>
> >>> --
> >>> You received this message because you are subscribed to the Google
> Groups "CAS Developer" group.
> >>> To unsubscribe from this group and stop receiving emails from it, send
> an email to cas-dev+u...@apereo.org.
> >>>
> >>> To view this discussion on the web visit
> https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAGSBKkfu1sjXEO1MPiq%3DjhhNhce%3DX6gy_LwASdvuMeRtUZ5hfQ%40mail.gmail.com
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "CAS Developer" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cas-dev+unsubscr...@apereo.org.
> To view this discussion on the web visit
> https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAGSBKkcJaC1QaBq%3DhcBqDWRYamUrfM_VGRrxerXompCKMAZNfA%40mail.gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups "CAS 
Developer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-dev+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAP279LzUP7Ttabb_P-VOjwp2687Zjubo_LP6fPfTGNbGiAbYPA%40mail.gmail.com.

Re: [cas-dev] Re: [cas-user] very slow ticket delivery on CAS 6.6 & redis ticket registry

[Jérôme LELEU]

Sure. I will test that on Monday (tomorrow is off in France :-)

Le jeu. 10 nov. 2022 à 17:27, Misagh  a écrit :

> Could I ask you to review and test this?
> https://github.com/mmoayyed/cas/compare/master...mmoayyed:cas:redis-fix
>
> On Thu, Nov 10, 2022 at 1:03 PM Misagh  wrote:
> >
> > Thank you Jérôme. I'll take a look.
> >
> > -- Misagh
> >
> > On Wed, Nov 9, 2022, 2:39 PM Jérôme LELEU  wrote:
> >>
> >> Hi,
> >>
> >> I have made a Redis performance test between v6.5.9 and v7.0.0-RC1 and
> figures are very relevant.
> >>
> >> In both cases, I have a CAS server using a Redis ticket registry
> (Docker image) and a custom authentication handler to validate any username
> starting with "jleleu".
> >> I have a script which performs a certain number of logins (without any
> service) for jleleuRANDOMVALUE.
> >> I have overriden the RedisTickerRegistry class to add time counting in
> v6.5:
> >>
> >> private static AtomicLong getTime = new AtomicLong();
> >> private static AtomicInteger nbGet = new AtomicInteger();
> >>
> >> @Override
> >> public Ticket getTicket(final String ticketId, final Predicate
> predicate) {
> >> val t0 = System.currentTimeMillis();
> >> try {
> >> val redisKey = getTicketRedisKey(encodeTicketId(ticketId));
> >> val t = this.client.boundValueOps(redisKey).get();
> >> if (t != null) {
> >> val result = decodeTicket(t);
> >> if (predicate.test(result)) {
> >> return result;
> >> }
> >> LOGGER.trace("The condition enforced by [{}] cannot
> successfully accept/test the ticket id [{}]", ticketId,
> >> predicate.getClass().getSimpleName());
> >> return null;
> >> }
> >> } catch (final Exception e) {
> >> LOGGER.error("Failed fetching [{}]", ticketId);
> >> LoggingUtils.error(LOGGER, e);
> >> } finally {
> >> val t1 = System.currentTimeMillis();
> >> val time = t1 - t0;
> >> val t = getTime.addAndGet(time);
> >> val n = nbGet.incrementAndGet();
> >> LOGGER.info("### GET time: {} ms | Average time: {} ms", time,
> t / n);
> >> }
> >> return null;
> >> }
> >>
> >>
> >> And in v7:
> >>
> >> @Override
> >> public Ticket getTicket(final String ticketId, final Predicate
> predicate) {
> >> val t0 = System.currentTimeMillis();
> >> try {
> >> val redisKey =
> RedisCompositeKey.builder().id(encodeTicketId(ticketId)).build().toKeyPattern();
> >> return getKeysStream(redisKey)
> >> .map(key -> redisTemplate.boundValueOps(key).get())
> >> .filter(Objects::nonNull)
> >> .map(this::decodeTicket)
> >> .filter(predicate)
> >> .findFirst()
> >> .orElse(null);
> >> } catch (final Exception e) {
> >> LOGGER.error("Failed fetching [{}]", ticketId);
> >> LoggingUtils.error(LOGGER, e);
> >> } finally {
> >> val t1 = System.currentTimeMillis();
> >> val time = t1 - t0;
> >> val t = getTime.addAndGet(time);
> >> val n = nbGet.incrementAndGet();
> >> LOGGER.info("### GET time: {} ms | Average time: {} ms", time,
> t / n);
> >> }
> >> return null;
> >> }
> >>
> >>
> >> Then I perform 1 000 and 10 000 logins (with my script) and check my
> logs to see the average time:
> >>
> >> v6.5.9:
> >> 1000 logins -> Average time: 3 ms
> >> 1 logins -> Average time: 3 ms
> >>
> >> v7.0.0-RC1:
> >> 1000 logins -> Average time: 22 ms
> >> 1 logins -> Average time: 195 ms
> >>
> >> So indeed, I notice a big performance issue.
> >>
> >> Do you need more information?
> >>
> >> Thanks.
> >> Best regards,
> >> Jérôme
> >>
> >>
> >> Le mar. 8 nov. 2022 à 07:56, Jérôme LELEU  a écrit :
> >>>
> >>> Hi,
> >>>
> >>> Yes, double indexing is harder than simple indexing as the second
> operation may fail and you should revert the first one (trans

Re: [cas-dev] Re: [cas-user] very slow ticket delivery on CAS 6.6 & redis ticket registry

[Jérôme LELEU]

Hi,

I think we were very good on 6.5.x. Only GET for common operations.

Our main problem was the full SCAN of tickets to check if a ticket is a TGT
and if the principal is the right one ("count/get SSO sessions").
For this one, I would have created a "double key indexing", big words for a
simple thing ;-)
On 6.5.x, we stored tickets this way: key=CAS_TICKET:ticketId =>
VALUE=serialized ticket
I propose for the "add ticket" operation to check if it is a TGT: in that
case, I would add to Redis: key=CAS_TICKET_USER:ticketId:userId =>
VALUE=nothing.
This way, we would "only" SCAN keys of TGT sessions to find the right user
(CAS_TICKET_USER:*:userId) and we would retrieve all the TGT identifiers
for a given user.
Then, a multi GET on these identifiers would find the SSO sessions of the
user.

The new key should be updated and deleted when the related TGT is updated
or deleted.

Thanks.
Best regards,
Jérôme



Le ven. 4 nov. 2022 à 18:57, Misagh  a écrit :

> I will take a second look to see if this can be improved, though I am
> intrigued by your "double key indexing" solution. Do you think you
> could put together some sort of POC to demonstrate this idea? The
> other solutions are non-starters. I'll also poke around to see what
> can be done to speed things up.
>
> On Fri, Oct 28, 2022 at 4:30 PM Jérôme LELEU  wrote:
> >
> > Hi,
> >
> > Moving the discussion to the dev mailing list.
> >
> > I think that using the userId suffix was made to improve performance
> when searching for user sessions.
> > Instead of scanning all existing keys to see if it is a TGT of this
> user, the idea was to scan only the tickets made for this user.
> >
> > About the solutions, I don't think we should remove the userId suffix as
> we would lose the previous improvement.
> > I think that a new cache would make sense to improve performance but I
> would store it directly in Redis to make things easier.
> > In fact, we would have a double keys indexing, maybe something like:
> CAS_TICKET_USER:ticketId:userId => (ticket) + CAS_TICKET:ticketId =>
> (CAS_TICKET_USER:ticketId:userId)
> >
> > @Misagh: what do you think of this problem and solutions?
> >
> > Thanks.
> > Best regards,
> > Jérôme
> >
> >
> > Le ven. 28 oct. 2022 à 14:05, Pascal Rigaux <
> pascal.rig...@univ-paris1.fr> a écrit :
> >>
> >> Solutions I can think of:
> >>
> >> - add a memory cache [ ticketId => redisKey ]
> >>(it should help a lot, even if it will still be slower than before
> in case of load balancing)
> >>
> >> - revert suffixing redis key with userid
> >>(easy change in RedisTicketRegistry.java)
> >>
> >>- and possibly add userid suffix in a UniqueTicketIdGenerator, the
> way HostNameBasedUniqueTicketIdGenerator suffixes with hostname
> >>  (but it may be hard to do...)
> >>
> >> cu
> >>
> >> On 28/10/2022 11:13, Jérôme LELEU wrote:
> >> > Hi,
> >> >
> >> > Thanks for raising the point.
> >> >
> >> > It's always hard to find a good balance between a generic design and
> performance.
> >> >
> >> > It seems to me that performing scans to get a ticket is not the best
> thing to do in terms of performance.
> >> >
> >> > The Redis ticket registry is commonly used and we should try to avoid
> any performance degradation.
> >> >
> >> > I have a few ideas in mind, but I'm not a Redis specialist: what do
> you propose?
> >> >
> >> > Thanks.
> >> > Best regards,
> >> > Jérôme
> >> >
> >> >
> >> > Le jeu. 27 oct. 2022 à 19:59, Pascal Rigaux <
> pascal.rig...@univ-paris1.fr <mailto:pascal.rig...@univ-paris1.fr>> a
> écrit :
> >> >
> >> > Hi,
> >> >
> >> > In 6.6.x Redis ticket registry key is suffixed with userid (since
> 6.6.0-RC4)
> >> >
> >> > This is great to know who owns a TGT or a ST.
> >> >
> >> > Alas, this means getting a TGT from Redis now requires a
> "SCAN"... which is much more costly.
> >> > Example: full "SCAN" is ~100 times slower then "GET" on our
> production Redis (dbsize ~100k, because we have 1 month rememberMe TGT)
> >> >
> >> >
> >> > For the record, getting a ST triggers
> >> > - on 5.3 : 8 redis "GET" on the TGT
> >> > - on 6.5 : 17 redis "GET" on the TGT
>

Re: [cas-dev] Re: [cas-user] very slow ticket delivery on CAS 6.6 & redis ticket registry

[Jérôme LELEU]

Hi,

Yes, double indexing is harder than simple indexing as the second operation
may fail and you should revert the first one (transactional aspect).
If we did that for all tickets, we would double the size of the keys, but
not the size of the database though.
And maybe we should have two different databases for better performance.

I will make a test to check the problem.

Thanks.
Best regards,
Jérôme


Le lun. 7 nov. 2022 à 18:30, Misagh  a écrit :

> > Our main problem was the full SCAN of tickets to check if a ticket is a
> TGT and if the principal is the right one ("count/get SSO sessions").
> > For this one, I would have created a "double key indexing", big words
> for a simple thing ;-)
> > On 6.5.x, we stored tickets this way: key=CAS_TICKET:ticketId =>
> VALUE=serialized ticket
> > I propose for the "add ticket" operation to check if it is a TGT: in
> that case, I would add to Redis: key=CAS_TICKET_USER:ticketId:userId =>
> VALUE=nothing.
> > This way, we would "only" SCAN keys of TGT sessions to find the right
> user (CAS_TICKET_USER:*:userId) and we would retrieve all the TGT
> identifiers for a given user.
> > Then, a multi GET on these identifiers would find the SSO sessions of
> the user.
>
> That's quite clever. But it's not without complications. These are not
> strictly blockers, but we should likely take these into account:
>
> Doing the double-indexing for a TGT would also imply that the same
> thing would/could be done for OIDC codes, access tokens and refresh
> tokens. For example, think of operations where you'd want to execute
> "get me all the access tokens issued to user X", or "all the refresh
> tokens issued to user Y", etc.  This would mean that the registry
> would have to somehow be tied to modules that present those extra
> ticket types though I imagine this can be somewhat solved with the
> ticket catalog concept. And of course, the registry size sort of
> grows. 10 TGTs for unique users would actually mean 20 entries, not to
> mention for every update/remove operation you'd be issuing double
> queries. So it's double the index, double the number of operations. At
> scale, I am not so sure this would actually be all that better, but I
> have not run any conclusive tests.
>
> I would also be interested to see an actual test that showcases the
> slowness. For example, I ran a test against a basic local redis
> cluster, 7.0.5. My test, added 1000 TGTs to the registry, then fetched
> them all, and then looped through the resultset asking the registry
> for each ticket that was fetched again. This operation completed in
> approx 13 seconds for non-encrypted tickets, and 14seconds encrypted
> tickets. Then, I reverted the pattern back to what 6.5 used to do, and
> I ran the same test, and I more or less saw the same execution time.
> Double checked to make sure there are no obvious mistakes. Is this
> also what you see? and if so, can you share some sort of a test that
> actually shows or demonstrates the problem?
>

-- 
You received this message because you are subscribed to the Google Groups "CAS 
Developer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-dev+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAP279LwhYW99H91VuM08%3D%3DET731CmMi%2Be8Dv-%3DwZu0eteBhcCg%40mail.gmail.com.

Re: [cas-dev] Re: [cas-user] very slow ticket delivery on CAS 6.6 & redis ticket registry

[Jérôme LELEU]

Hi,

I have made a Redis performance test between v6.5.9 and v7.0.0-RC1 and
figures are very relevant.

In both cases, I have a CAS server using a Redis ticket registry (Docker
image) and a custom authentication handler to validate any username
starting with "jleleu".
I have a script which performs a certain number of logins (without any
service) for *jleleuRANDOMVALUE*.
I have overriden the *RedisTickerRegistry* class to add time counting in
v6.5:

private static AtomicLong getTime = new AtomicLong();
private static AtomicInteger nbGet = new AtomicInteger();

@Override
public Ticket getTicket(final String ticketId, final Predicate
predicate) {
val t0 = System.currentTimeMillis();
try {
val redisKey = getTicketRedisKey(encodeTicketId(ticketId));
val t = this.client.boundValueOps(redisKey).get();
if (t != null) {
val result = decodeTicket(t);
if (predicate.test(result)) {
return result;
}
LOGGER.trace("The condition enforced by [{}] cannot
successfully accept/test the ticket id [{}]", ticketId,
predicate.getClass().getSimpleName());
return null;
}
} catch (final Exception e) {
LOGGER.error("Failed fetching [{}]", ticketId);
LoggingUtils.error(LOGGER, e);
} finally {
val t1 = System.currentTimeMillis();
val time = t1 - t0;
val t = getTime.addAndGet(time);
val n = nbGet.incrementAndGet();
LOGGER.info("### GET time: {} ms | Average time: {} ms", time, t / n);
}
return null;
}


And in v7:

@Override
public Ticket getTicket(final String ticketId, final Predicate
predicate) {
val t0 = System.currentTimeMillis();
try {
val redisKey =
RedisCompositeKey.builder().id(encodeTicketId(ticketId)).build().toKeyPattern();
return getKeysStream(redisKey)
.map(key -> redisTemplate.boundValueOps(key).get())
.filter(Objects::nonNull)
.map(this::decodeTicket)
.filter(predicate)
.findFirst()
.orElse(null);
} catch (final Exception e) {
LOGGER.error("Failed fetching [{}]", ticketId);
LoggingUtils.error(LOGGER, e);
} finally {
val t1 = System.currentTimeMillis();
val time = t1 - t0;
val t = getTime.addAndGet(time);
val n = nbGet.incrementAndGet();
LOGGER.info("### GET time: {} ms | Average time: {} ms", time, t / n);
}
return null;
}


Then I perform 1 000 and 10 000 logins (with my script) and check my logs
to see the average time:

v6.5.9:
1000 logins -> Average time: 3 ms
1 logins -> Average time: 3 ms

v7.0.0-RC1:
1000 logins -> Average time: 22 ms
1 logins -> Average time: 195 ms

So indeed, I notice a big performance issue.

Do you need more information?

Thanks.
Best regards,
Jérôme


Le mar. 8 nov. 2022 à 07:56, Jérôme LELEU  a écrit :

> Hi,
>
> Yes, double indexing is harder than simple indexing as the second
> operation may fail and you should revert the first one (transactional
> aspect).
> If we did that for all tickets, we would double the size of the keys, but
> not the size of the database though.
> And maybe we should have two different databases for better performance.
>
> I will make a test to check the problem.
>
> Thanks.
> Best regards,
> Jérôme
>
>
> Le lun. 7 nov. 2022 à 18:30, Misagh  a écrit :
>
>> > Our main problem was the full SCAN of tickets to check if a ticket is a
>> TGT and if the principal is the right one ("count/get SSO sessions").
>> > For this one, I would have created a "double key indexing", big words
>> for a simple thing ;-)
>> > On 6.5.x, we stored tickets this way: key=CAS_TICKET:ticketId =>
>> VALUE=serialized ticket
>> > I propose for the "add ticket" operation to check if it is a TGT: in
>> that case, I would add to Redis: key=CAS_TICKET_USER:ticketId:userId =>
>> VALUE=nothing.
>> > This way, we would "only" SCAN keys of TGT sessions to find the right
>> user (CAS_TICKET_USER:*:userId) and we would retrieve all the TGT
>> identifiers for a given user.
>> > Then, a multi GET on these identifiers would find the SSO sessions of
>> the user.
>>
>> That's quite clever. But it's not without complications. These are not
>> strictly blockers, but we should likely take these into account:
>>
>> Doing the double-indexing for a TGT would also imply that the same
>> thing would/could be done for OIDC codes, access tokens and refresh
>> tokens. For example, think of operations where you'd want to execute
>> "get me all the access tokens issued to user X", or "a

Re: [cas-dev] Re: [cas-user] very slow ticket delivery on CAS 6.6 & redis ticket registry

[Jérôme LELEU]

Hi,

I have made new tests.

With the new implementation, I have experienced Redis crashes, but I'm not
sure this is meaningful.
In any case, I have updated to Redis v7 with 500Mo of memory.

I have launched my previous scenario again (10 000 logins).
CAS v6.5: Average time: 2 ms
CAS v7.0.0 fix REDIS: Average time: 0 ms

Things are now blazing fast with the new implementation but I see you have
added a memory cache so this is expected on a single node.

So I have created a 2 nodes scenario with 10 000 login?service + service
ticket validation, each call (GET /login, POST /login, GET
/serviceValidate) being performed on a different node than the previous
call (round robin).

CAS v6.5 :
Average time node 1: 1 ms
Average time node 2: 1 ms

CAS v7.0.0 fix REDIS :
Average time node 1: 2 ms
Average time node 2: 2 ms

While it performs better on CAS v6.5, it now performs very well on CAS v7
as well.

Did you change something else in addition to the cache?

Thanks.
Best regards,
Jérôme


Le jeu. 10 nov. 2022 à 17:47, Jérôme LELEU  a écrit :

> Sure. I will test that on Monday (tomorrow is off in France :-)
>
> Le jeu. 10 nov. 2022 à 17:27, Misagh  a écrit :
>
>> Could I ask you to review and test this?
>> https://github.com/mmoayyed/cas/compare/master...mmoayyed:cas:redis-fix
>>
>> On Thu, Nov 10, 2022 at 1:03 PM Misagh  wrote:
>> >
>> > Thank you Jérôme. I'll take a look.
>> >
>> > -- Misagh
>> >
>> > On Wed, Nov 9, 2022, 2:39 PM Jérôme LELEU  wrote:
>> >>
>> >> Hi,
>> >>
>> >> I have made a Redis performance test between v6.5.9 and v7.0.0-RC1 and
>> figures are very relevant.
>> >>
>> >> In both cases, I have a CAS server using a Redis ticket registry
>> (Docker image) and a custom authentication handler to validate any username
>> starting with "jleleu".
>> >> I have a script which performs a certain number of logins (without any
>> service) for jleleuRANDOMVALUE.
>> >> I have overriden the RedisTickerRegistry class to add time counting in
>> v6.5:
>> >>
>> >> private static AtomicLong getTime = new AtomicLong();
>> >> private static AtomicInteger nbGet = new AtomicInteger();
>> >>
>> >> @Override
>> >> public Ticket getTicket(final String ticketId, final Predicate
>> predicate) {
>> >> val t0 = System.currentTimeMillis();
>> >> try {
>> >> val redisKey = getTicketRedisKey(encodeTicketId(ticketId));
>> >> val t = this.client.boundValueOps(redisKey).get();
>> >> if (t != null) {
>> >> val result = decodeTicket(t);
>> >> if (predicate.test(result)) {
>> >> return result;
>> >> }
>> >> LOGGER.trace("The condition enforced by [{}] cannot
>> successfully accept/test the ticket id [{}]", ticketId,
>> >> predicate.getClass().getSimpleName());
>> >> return null;
>> >> }
>> >> } catch (final Exception e) {
>> >> LOGGER.error("Failed fetching [{}]", ticketId);
>> >> LoggingUtils.error(LOGGER, e);
>> >> } finally {
>> >> val t1 = System.currentTimeMillis();
>> >> val time = t1 - t0;
>> >> val t = getTime.addAndGet(time);
>> >> val n = nbGet.incrementAndGet();
>> >> LOGGER.info("### GET time: {} ms | Average time: {} ms", time,
>> t / n);
>> >> }
>> >> return null;
>> >> }
>> >>
>> >>
>> >> And in v7:
>> >>
>> >> @Override
>> >> public Ticket getTicket(final String ticketId, final Predicate
>> predicate) {
>> >> val t0 = System.currentTimeMillis();
>> >> try {
>> >> val redisKey =
>> RedisCompositeKey.builder().id(encodeTicketId(ticketId)).build().toKeyPattern();
>> >> return getKeysStream(redisKey)
>> >> .map(key -> redisTemplate.boundValueOps(key).get())
>> >> .filter(Objects::nonNull)
>> >> .map(this::decodeTicket)
>> >> .filter(predicate)
>> >> .findFirst()
>> >> .orElse(null);
>> >> } catch (final Exception e) {
>> >> LOGGER.error("Failed fetching [{}]", ticketId);
>> >>     LoggingUtils.

Re: [cas-dev] Re: [cas-user] very slow ticket delivery on CAS 6.6 & redis ticket registry

[Jérôme LELEU]

EXCELLENT!

Le mar. 15 nov. 2022 à 04:54, Misagh  a écrit :

>
>
>
> On Mon, Nov 14, 2022, 4:58 PM Jérôme LELEU  wrote:
>
>> Hi,
>>
>> I have made new tests.
>>
>> With the new implementation, I have experienced Redis crashes, but I'm
>> not sure this is meaningful.
>> In any case, I have updated to Redis v7 with 500Mo of memory.
>>
>
> I ran into something similar. I think this is mainly due to the large
> number of operations and tickets and that the redis setup is not exactly
> tuned to handle the load.
>
>
>>
>> CAS v6.5 :
>> Average time node 1: 1 ms
>> Average time node 2: 1 ms
>>
>> CAS v7.0.0 fix REDIS :
>> Average time node 1: 2 ms
>> Average time node 2: 2 ms
>>
>> While it performs better on CAS v6.5, it now performs very well on CAS v7
>> as well.
>>
>> Did you change something else in addition to the cache?
>>
>
> Yes I am experimenting with the ticket pattern lookup to not use scanning.
> This seems to be good enough even without the cache. If you disable the
> cache altogether on a single node by forcing its capacity to be at 0, (i.e
> never cache anything) you should see comparable performance numbers. This
> should fit the scope of 6.6, if we were to backport.
>
> I'd like to keep the cache changes in master and continue testing. Cache
> invalidation can be very tricky here to make sure updates and changes to
> one ticket on one node is correctly found and processed on another. Given
> the current caching model is incredibly fast, I'd like to stick to this
> strategy and work out the other possible issues with clustered setups and
> event sinks. If I cannot make it work reliably, then I would consider
> either removing the cache or changing its structure. It would be slower
> than what it is now, but still very very fast.
>
> And if this technique works ok, it might be something to extend to other
> registry plugins as the need comes up.
>
>
>
>
>>>> --
> You received this message because you are subscribed to the Google Groups
> "CAS Developer" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cas-dev+unsubscr...@apereo.org.
> To view this discussion on the web visit
> https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAGSBKkfu1sjXEO1MPiq%3DjhhNhce%3DX6gy_LwASdvuMeRtUZ5hfQ%40mail.gmail.com
> <https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAGSBKkfu1sjXEO1MPiq%3DjhhNhce%3DX6gy_LwASdvuMeRtUZ5hfQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups "CAS 
Developer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-dev+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAP279LyJrfR-GEkz6OH_9QW%2BqNjak-rmaksp0A-zu8pdFVp4XQ%40mail.gmail.com.