Thanks for the tip on the ultimate edition. Cas uses a number of keys for various tasks. If the key is not present in your config, cas will create one on boot. It will be different each time cas starts and, of course, anything persisted with the earlier key will no longer be accessible. There will be some log messages to let you know:
cas | 2023-08-25 18:52:34,189 WARN [ org.aper.cas.util.ciph.BaseStringCipherExecutor] - <Secret key for encryption is not defined for [Ticket-granting Cookie]; CAS will attempt to auto-generate the encryption key> [main] cas | 2023-08-25 18:52:34,201 WARN [ org.aper.cas.util.ciph.BaseStringCipherExecutor] - <Generated encryption key [-Tt6GwcfiQu6Sg_gwYlnUzxhRxOJVFbT6gQra7tSwzs] of size [256] for [Ticket-granting Cookie]. The generated key MUST be added to CAS settings: cas | cas | cas.tgc.crypto.encryption.key=-Tt6GwcfiQu6Sg_gwYlnUzxhRxOJVFbT6gQra7tSwzs cas | cas | > [main] cas | 2023-08-25 18:52:34,204 WARN [ org.aper.cas.util.ciph.BaseStringCipherExecutor] - <Secret key for signing is not defined for [Ticket-granting Cookie]. CAS will attempt to auto-generate the signing key> [main] cas | 2023-08-25 18:52:34,204 WARN [ org.aper.cas.util.ciph.BaseStringCipherExecutor] - <Generated signing key [Gc2fjXd0ev0L7r_FnwN1XStSxYgatoeoipld5nGt78KfKM5FBTwWYbsvOox4LDcvCLmP8-4JEdDkmzvpJJ1kWg] of size [512] for [Ticket-granting Cookie]. The generated key MUST be added to CAS settings: cas | cas | cas.tgc.crypto.signing.key=Gc2fjXd0ev0L7r_FnwN1XStSxYgatoeoipld5nGt78KfKM5FBTwWYbsvOox4LDcvCLmP8-4JEdDkmzvpJJ1kWg You can use the key values generated by cas rather than trying to create them yourself. It looks like the web runner is pulling from the repository instead of using the built files in the project. There is this gradlew command, publishToMavenLocal, to install locally. (See bottom of https://apereo.github.io/cas/development/developer/Build-Process.html#sample-build-aliases.) You can also copy the jar file, to which you made code changes, to your ~/.m2/repository/... Ray On Fri, 2023-08-25 at 11:18 +0200, spfma.tech via CAS Community wrote: Notice: This message was sent from outside the University of Victoria email system. Please be cautious with links and sensitive information. Hi, I thought the Ultimate edition has it : https://www.jetbrains.com/help/idea/remote-development-starting-page.html But I will never be offered this tool anyhow ! I am using my main production logfile at "/etc/cas/config log4j2.xml", with all levels between "trace" and "debug". And I see plenty of debug messages so I think it's ok. I am now studying the problem with a simple CAS instance built from the sources, with a dummy JSON service and the internal "casuser" account. I just added "cas-server-support-json-service-registry", ""cas-server-support-gauth" and "cas-server-support-gauth-couchdb" and the related "cas.properties" configuration directives : ########################## # MFA (global settings) # ########################## cas.authn.mfa.triggers.global.global-provider-id:mfa-gauth #cas.authn.mfa.triggers.global.global-provider-id: mfa-simple ######################## # Google Authenticator # ######################## cas.authn.mfa.gauth.core.multiple-device-registration-enabled:true cas.authn.mfa.gauth.core.issuer: CAS cas.authn.mfa.gauth.core.label: OUR_CORP cas.authn.mfa.gauth.couch-db.create-if-not-exists:true cas.authn.mfa.gauth.couch-db.db-name: cas_gauth cas.authn.mfa.gauth.couch-db.password: password cas.authn.mfa.gauth.couch-db.username: admin cas.authn.mfa.gauth.couch-db.url: http://localhost:5984 CouchDb is running as a local Docker container, with a persistent volume (I had to create the database manually, as in spite of having set "cas.authn.mfa.gauth.couch-db.create-if-not-exists" to true, there are no design documents inside and authenticators registering can not work. There is an older post in this ML about that, I used the informations they provided and it works after manually creating the missing items). When I login for the first time, I am asked to pair a new authenticator and the process is successful. And can login again and again it's ok. If I check the database, I have a record related to this authenticator, having a name, and id and user name. If I restart CAS, the database content is still the same of course but the codes provided by the authenticator are not working anymore, as if they were wrong. And I have an error message in the logs : 2023-08-25 11:04:22,487 ERROR [org.apereo.cas.authentication.DefaultAuthenticationManager] - <Authentication has failed. Credentials may be incorrect or CAS cannot find authentication handler that supports [GoogleAuthenticatorTokenCredential(super=OneTimeTokenCredential(token=********), accountId=1692865323865)] of type [GoogleAuthenticatorTokenCredential]. Examine the configuration to ensure a method of authentication is defined and analyze CAS logs at DEBUG level to trace the authentication event.> 2023-08-25 11:04:22,487 ERROR [org.apereo.cas.authentication.DefaultAuthenticationManager] - <[GoogleAuthenticatorAuthenticationHandler]: [Secret cannot be null.]> I still have this record in the databasen with id=1692865323865 in the database, related to the "casuser" and the registered authenticator". The "secretKey" property is still not null. I have set "cas.authn.mfa.gauth.core.multiple-device-registration-enabled" to true, and I am indeed allowed to pair additional authenticators with my accounts. But doing so gives no result, there is still only one record in the database. If I manually add a forged record corresponding to a second authenticator, it's better, I have a list of authenticators I can choose. So I decided to study the internals a bit further, by adding logging directives here and there. But I have more and more the feeling something is wrong or is beyond my current understanding to say the least. As you suggested, maybe I am looking at the wrong place, expecting to see log messages from methods which are never called in this use case ? There is some gargabe collector removing the old tokens (and it's working flawlessly) logging something like : 2023-08-25 11:01:11,218 DEBUG [org.apereo.cas.gauth.token.GoogleAuthenticatorCouchDbTokenRepository] - <Removing tokens older than [2023-08-25T11:00:41.218288]> After greping the whole source tree, it seems this message is unique and indeed located in "cleanInternal" method from "support/cas-server-support-gauth-couchdb/src/main/java/org/apereo/cas/gauth/token/GoogleAuthenticatorCouchDbTokenRepository.java". Sounds logical. So my idea was to simply alter the message, rebuild the app and see if this simple modification is working. And guess what ... it's not working as expected. After starting from scratch ("gradlew clean" and deletion of "~/.gradle/caches"), I built the app again and even tried to execute the war from "cas/webapp/cas-server-webapp-jetty/build/libs/cas-server-webapp-jetty-6.6.11-SNAPSHOT.war" It's running but the log message is still displayin the same text as in original source code. Just for science, I tried with "bootRun" and it's still the same. So I used the Fernflower package provided with Idea installation to see the source code from the generated classe. The compiled class from the code I have modified has the expected content (support/cas-server-support-gauth-couchdb/build/classes/java/main/org/apereo/cas/gauth/token/GoogleAuthenticatorCouchDbTokenRepository.class). And it's been created or modified a couple of minutes after I modified the source code and rebuilt. So far it's normal. So what is used in the webapp ? After exploding "webapp/cas-server-webapp-jetty/build/libs/cas-server-webapp-jetty-6.6.11-SNAPSHOT.war" and its "WEB-INF/lib/cas-server-support-gauth-couchdb-6.6.11-SNAPSHOT.jar" package, I discovered two things : - the file "org/apereo/cas/gauth/token/GoogleAuthenticatorCouchDbTokenRepository.class" has a modification time set ... two days ago, at a time I am not even at work. - the content is still the original one, without my modifications. Having cleaned the build tree and destroyed all cache, I have no explanations. So maybe I am right and wrong at the same time, having put debug outputs at the right locations but unable to see them because of another code being executed. So far i am a bit stuck in the middle of the twilight zone. Regards Le 24-Aug-2023 17:58:38 +0200, r...@uvic.ca a écrit: The paid for version of intellij does not support remote editing either (sigh). Your dev setup sounds fine and you should not have to worry about your local machine since it is only used for editing. I only use intellij for code completion and class/method references. I always build/run on the command line. Are you creating a log4j2.xml file or adding to the one already in the project, https://github.com/apereo/cas/blob/6.6.x/webapp/cas-server-webapp-resources/src/main/resources/log4j2.xml When running, the default location for the log config file is /etc/cas/log4j2.xml (at least when using the overlay), so make sure you are editing the correct file. By setting your custom loggers to 'error' or 'fatal', you do not have to edit the log config. When you say no records are in the database after a restart; are you talking about a cas restart, a couchdb restart, or both? Is it possible that a cas restart re-initializes the db? (I have not used any cas db functionality, so am unfamiliar with its operation or config.) Can you check that the records exist in couchdb? How are cas tickets being stored? I would guess that cas finds a record in couchdb by TGT id. If the ticket store is lost on a restart, then cas would have no way of finding anything in the db. (Again, I know nothing of how cas uses databases.) Ray On Thu, 2023-08-24 at 09:36 +0200, spfma.tech via CAS Community wrote: Notice: This message was sent from outside the University of Victoria email system. Please be cautious with links and sensitive information. Hi, Thanks for your answer. https://github.com/apereo/cas/blob/6.6.x/webapp/cas-server-webapp-resources/src/main/resources/log4j2.xml I chose this storage system because my goal is to setup an active/passive pair of servers (with continous db replication on the passive side and automatic seemless failover) in order to provider high availability. It was the only supported backend I have found providing an easy way to achieve this goal (no three tier cluster with qorum and/or manual failover with conventional RDBMS). But according you John's answer, I think I will have to change my mind anyway. As my computer does not meet the requirements for serious Java developement, I am working remotely on an beefed up VM with plenty of RAM and CPU cores. And for that, VSCode has a very nice remote session extension, using ssh. Since Java related extensions don't seem to work correctly this way (maybe they work better localy, I don't have enough resources to test it), I am indeed using two shell sessions to run commands : one for building (clean build), and the other one for running (bootRun). I have seen some posts here and there relating unexplainable problems with Gradle, and wiping out all the folders solved them. So I gave a try too ! My actual log4j config has a logger defined this way : <Loggername="org.apereo.cas"level="debug"> <appender-refref="casFile"/> <appender-refref="casConsole"/> <!-- <appender-ref ref="casSyslog" />--> </Logger> And I am adding "LOGGER. debug" directives here in there. Should it be ok ? I had a look at several IDE, and IDEA free has no remote support unfortunately. Need to have a look at Eclipse and Netbeans too, but it seems they have the same limitations. So better make a wise choice before investing time and energy in such a complex product. Regards Le 23-Aug-2023 19:53:05 +0200, r...@uvic.ca a écrit: Could you use a different storage system? I do not see the couchdb module in the current development branch. Not sure if it is being removed or if a different module takes on that feature. Instead of running gradlew in vscode, you can run it from the command line. The 'clean' part of the command will remove all .class files; no need to get rid of gradle directories unless you are changing gradle version (which you should not). Once you build the project, remove 'clean'; only modified packages will be rebuilt (will be fine for logging, but not for api changes). It is possible that method is not being called. You could put your logging statement in every method in that class to be sure. Also, use error level logging. Default logging for that class may not show at info or debug. Or add to log4j2.xml: <AsyncLogger name="org.apereo.cas.couchdb.gauth.credential" level="trace"> If you want a more 'capable' development environment, here are some notes on intellij (I think there is a free version), https://apereo.github.io/cas/development/developer/Build-Process.html#intellij-idea Ray On Wed, 2023-08-23 at 17:43 +0200, spfma.tech via CAS Community wrote: Notice: This message was sent from outside the University of Victoria email system. Please be cautious with links and sensitive information. Hi, I am still trying to understand what is wrong with "cas-server-support-gauth-couchdb" (only the first authenticator is recorded in the database, none is working anymore after a restart). As I am not a Java dev (I don't have the skills and don't have the most convenient tools), my idea was to add some logging directives here and there to trace the process, using the latest branch of the application source code (not the overlay one). Can someone confirm I am doing the right way : - add "import lombok.extern.slf4j.Slf4j;" if missing on the top of the class file - anotate the class definition with "@Slf4j" - put stuff like "LOGGER.debug" or "LOGGER.info" as needed VSCode is my tool, and it seems convenient extensions for Java/Maven/Gradle are not able to handle a big project like CAS (language server crashing and restarting all the time, Gradle extensions unable to build a tree of all subprojects without crashing, ...) so I don't mind using the good old manual way instead of wasting time. After modifying the code here and there, I rebuild the whole app with "./gradlew clean build --parallel --configure-on-demand --stacktrace --no-daemon -x checkstyleMain" at the root of the project. And "cas/webapp/cas-server-webapp-jetty$ ../../gradlew bootRun --parallel --configure-on-demand --build-cache --stacktrace --no-daemon -x checkstyleMain" allows me to try it (we use it with Jetty in production). The app is running, I can reproduce the problems but I have the feeling my modifications don't exist as none of my custom logging messages is displayed. For an example, I added a simple logging flag in this file "support/cas-server-support-gauth-couchdb/src/main/java/org/apereo/cas/couchdb/gauth/credential/GoogleAuthenticatorAccountCouchDbRepository.java" this way : @View(name="by_username", map="function(doc) { if(doc.secretKey) { emit(doc.username, doc) } }") public List<CouchDbGoogleAuthenticatorAccount>findByUsername(finalStringusername) { LOGGER.debug("[MY_DEBUG_STUFF] findByUsername@GoogleAuthenticatorAccountCouchDbRepository={}", username); try { return queryView("by_username",username.trim().toLowerCase()); } catch (finalDocumentNotFoundExceptione) { LOGGER.trace(e.getMessage(), e); } return newArrayList<>(0); } as I think it's the one responsible for database lookup, according to the request I have seen coming on database side. But nothing in the logs ... Maybe I am not tagging the right source file ? So why not tweak a known existing log message, it is safer. In "support/cas-server-support-gauth-couchdb/src/main/java/org/apereo/cas/gauth/token/GoogleAuthenticatorCouchDbTokenRepository.java" I changed the message in "cleanInternal" method. The string "Removing tokens older than" is only found in this file, so I think it's spot on. After rebuilding and restarting the application, I still get the original message in my logs. DEBUG [org.apereo.cas.gauth.token.GoogleAuthenticatorCouchDbTokenRepository] - <Removing tokens older than [2023-08-23T17:37:11.946486] Could someone tell me what I am missing or doing wrong ? Of course, I have deleted all Gradle dirs, used a find to delete all ".class" files and rebuild the projects several times but I am stuck. Reagrds ________________________________ FreeMail powered by mail.fr<https://mail.fr> ________________________________ FreeMail powered by mail.fr<https://mail.fr> ________________________________ FreeMail powered by mail.fr<https://mail.fr> -- - 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/c7637093427dcac76cda3a39207e750fbed2f094.camel%40uvic.ca.