Bug #4352
fermé
Nombreuses erreurs d'authentifications déjà connecté
Ajouté par Emmanuel GRANGE il y a environ 11 ans. Mis à jour il y a environ 11 ans.
100%
Description
Bonjour,
Nous avons ÉNORMÉMENT d'erreur d'authentification dans les traces du portail.
Ces erreurs surviennent alors que l'utilisateur est déjà connecté, ou même parfois alors que l'utilisateur est déconnecté, et qu'il ne fait aucune tentative de connexion.
Le portail a planté aujourd'hui et les seules erreurs que j'ai pu constater dans tous les fichiers de logs sont ces problèmes d'authentification.
Il est d'autant plus gênant que les fichiers de logs ont considérablement augmentés depuis le passage en v5.11.1
Fichiers
| server.20130228.zip (1,01 Mo) server.20130228.zip | Emmanuel GRANGE, 28/02/2013 17:25 | ||
| traces.20130228.zip (443 ko) traces.20130228.zip | Emmanuel GRANGE, 28/02/2013 17:25 | ||
| plantage.server.20130301.log.gz (11,1 ko) plantage.server.20130301.log.gz | Emmanuel GRANGE, 01/03/2013 14:08 |
Mis à jour par Nicolas Eysseric il y a environ 11 ans
- Statut changé de New à Feedback
Merci de nous fournir un extrait de vos traces... et notamment celles à l'heure du "plantage".
Mis à jour par Emmanuel GRANGE il y a environ 11 ans
- Fichier server.20130228.zip server.20130228.zip ajouté
- Fichier traces.20130228.zip traces.20130228.zip ajouté
Ci-joints les traces de la journée.
Le plantage est survenue le 28/02/2013 vers 9:15 et a fini de redémarrer à 9:27
Mis à jour par Nicolas Eysseric il y a environ 11 ans
- Statut changé de Feedback à Assigned
- Assigné à mis à Emmanuel Hugonnet
L'erreur suivante se produit en effet très régulièrement. Elle fait référence à la fois à Jackrabbit/Webdav et à l'authentification. Je doute qu'il s'agisse d'une édition en ligne vu le nombre d'erreur. Est-ce vraiment lié à Jackrabbit ou à un effet de bord quelconque ?
Ce qui étonnant c'est que le user n'est pas cohérent vis à vis du domaine. En effet, le user fmaurice est dans le domaine 3 (MGI) pas dans le domaine 0 ?!
Aucune autre erreur qui peut expliquer le "plantage" du serveur...
28/02/13-09:27:13,564 - ERROR : authentication.EX_USER_REJECTED | MODULE : authentication.LoginPasswordAuthentication.authenticate() | L'authentification de l'utilisateur a echouee (DomainId=0;User=fmaurice)
L'authentification a echoue (ci-joint l'echec du dernier serveur)
nested (Deepest) :
Utilisateur non trouve ou attribut Login invalide
com.stratelia.silverpeas.authentication.AuthenticationBadCredentialException: authentication.EX_USER_NOT_FOUND
at com.stratelia.silverpeas.authentication.AuthenticationSQL.internalAuthentication(AuthenticationSQL.java:213)
at com.stratelia.silverpeas.authentication.Authentication.internalAuthentication(Authentication.java:105)
at com.stratelia.silverpeas.authentication.Authentication.authenticate(Authentication.java:81)
at com.stratelia.silverpeas.authentication.AuthenticationServer.authenticate(AuthenticationServer.java:102)
at com.stratelia.silverpeas.authentication.LoginPasswordAuthentication.authenticate(LoginPasswordAuthentication.java:219)
at com.stratelia.webactiv.jaas.SilverpeasLoginModule.login(SilverpeasLoginModule.java:136)
at com.silverpeas.jcrutil.security.ProxyLoginModule.login(ProxyLoginModule.java:62)
at org.apache.jackrabbit.core.security.authentication.LocalAuthContext.login(LocalAuthContext.java:86)
at org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1465)
at org.apache.jackrabbit.core.jndi.BindableRepository.login(BindableRepository.java:162)
at org.apache.jackrabbit.server.SessionProviderImpl.getSession(SessionProviderImpl.java:88)
at org.apache.jackrabbit.webdav.simple.DavSessionProviderImpl.attachSession(DavSessionProviderImpl.java:85)
at org.apache.jackrabbit.webdav.server.AbstractWebdavServlet.service(AbstractWebdavServlet.java:247)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:324)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242)
at com.silverpeas.whitePages.filters.ComponentRequestRouterFilter.doFilter(ComponentRequestRouterFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242)
at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:181)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501)
at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.event(CatalinaContext.java:285)
at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.invoke(CatalinaContext.java:261)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:88)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:100)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:159)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:53)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:654)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951)
at java.lang.Thread.run(Thread.java:662)
Mis à jour par Emmanuel Hugonnet il y a environ 11 ans
C'est 'normal' car avec l'édition webdav on ne passe pas de domainId, donc on essaye d'authentifier l'utilisateur sur l'ensemble des domaines.
Par contre les queues JMS ont elles été purgées ? Car même si le souci d'engorgement a été corrigé, cela ne résout pas l'engorgement existant.
Il faut se connecter via la console d'administration de JBoss et vérifier le nombre de 'listeners'.
Mis à jour par Emmanuel Hugonnet il y a environ 11 ans
- Version cible mis à Version 5.11.2
- % réalisé changé de 0 à 50
Après vérification ce n'est pas JMS la cause, les topics étant bien vides.
J'ai corrigé le code de manière à obtenir la liste des domaines pour lesquels un utilisateur avec le login peut être authentifié.
Le code devrait donc être plus léger et moins soumis à des erreurs.
Mis à jour par Emmanuel GRANGE il y a environ 11 ans
- Fichier plantage.server.20130301.log.gz plantage.server.20130301.log.gz ajouté
Le portail a à nouveau planté ce matin vers 11:00.
Il s'est arrêté d'un seul coup, sans aucun ralentissement ou erreur précurseur.
Toujours de nombreuses erreurs d'authentification.
Y-a-t'il une relation possible, ou dois-je ouvrir un nouveau ticket pour cela ?
Mis à jour par David Lesimple il y a environ 11 ans
Emmanuel, je te conseille de rétablir dans MGISettings.xml une configuration correcte, conformément au mail que je t'ai envoyé.
Mis à jour par Emmanuel Hugonnet il y a environ 11 ans
Nous pouvons vous proposer d'installer la version 5.11.2 en beta pour voir si cela corrige votre souci.
Mis à jour par Emmanuel GRANGE il y a environ 11 ans
David Lesimple a écrit :
Emmanuel, je te conseille de rétablir dans MGISettings.xml une configuration correcte, conformément au mail que je t'ai envoyé.
D'accord, je vais corriger le MGISettings, mais je ne vois pas en quoi cela résoudra notre problème.
Est-il possible de savoir quel fichier de configuration le portail utilise ?
Mis à jour par David Lesimple il y a environ 11 ans
Disons que tu as fait un paramétrage pour gérer l'expiration du mot de passe sur un fichier de domaine qui n'est pas lu par Silverpeas car pas dans le bon répertoire.
En clair, tu modifies le fichier autDomainMGI dans org/silverpeas/authentication alors que Silverpeas lit le fichier autDomainMGI qui se trouve dans com/stratelia/silverpeas/authentication.
Cela ne règlera peut-etre pas le problème, mais ça évitera d'autres erreurs plus tard.
Mis à jour par Nicolas Eysseric il y a environ 11 ans
- Statut changé de Assigned à Closed
- % réalisé changé de 50 à 100
Validé et intégré...