Archiva
  1. Archiva
  2. MRM-728

After successful admin login archiva reacts as if user is guest

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Won't Fix
    • Affects Version/s: 1.0.1
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:
      linux
    • Number of attachments :
      3

      Description

      I ran Archiva on my windows box and, after configuring the admin user, I was able to login. The header of the web page identified me as Administrator (admin) and I could see all the expected functions on the left hand frame. So far so good.

      I had Archiva installed on a linux box and started. I surfed to the box from Windows and configured the admin user. But when I logged in as admin I got a page with only Search/FindArtifact/Browse functions. The header page reads "Login - Register". It is as if I am not logged in and am seeing the guest functions. Note that if I log in with a deliberately incorrect password then I get an error message as expected. But logging in with the right credentials appears to fail silently.

      As a result I cannot deploy any artifacts into Archiva, I cannot roll out the maven/subversion/archiva based edition of our in-house project, and I fear my time is limited!

      1. archiva.log
        13 kB
        Robin Roos
      2. archiva.log.debug.signon.txt
        3 kB
        Robin Roos
      1. advancedprivacysettings.jpg
        20 kB

        Activity

        Hide
        Brett Porter added a comment -

        There are two things to investigate:

        • was there anything in the logs or anything additional in the URL when the login appeared to work but didn't?
        • what browser is in use? Could there be a cookie issue here?

        Thanks!

        Show
        Brett Porter added a comment - There are two things to investigate: was there anything in the logs or anything additional in the URL when the login appeared to work but didn't? what browser is in use? Could there be a cookie issue here? Thanks!
        Hide
        Arun Nachimuthu added a comment -

        I am facing exactly the same issue.

        Archiva 1.0.1 on Tomcat 6.x RedHat Linux.

        Once i login, I get only the page with only Search/FindArtifact/Browse functions.

        This issue is reproducable only if I use IE7 as the browser. When I try to login with FireFox everything is fine.

        Was not able to reproduce this in windows with exactly the same setup/installation instrucations.

        Thanks

        Show
        Arun Nachimuthu added a comment - I am facing exactly the same issue. Archiva 1.0.1 on Tomcat 6.x RedHat Linux. Once i login, I get only the page with only Search/FindArtifact/Browse functions. This issue is reproducable only if I use IE7 as the browser. When I try to login with FireFox everything is fine. Was not able to reproduce this in windows with exactly the same setup/installation instrucations. Thanks
        Hide
        Robin Roos added a comment - - edited

        My browser is IE version 6.0.2900.2180.xpsp_sp2_gdr.070227-2254 which I take to mean "IE 6.0 SP 2".

        The bank does not permit Firefox (which intrigues me, as I see Firefox as less of a risk than IE !).

        The logs (archiva.log) did not show anything when I signed on "successfully" but did have messages that indicated "unsuccessful login" (at which point I got to the unsuccessful login page).

        n the successful login scenario the archiva.log has no additional entries and I am directed back to the opening page with only three available functions.

        The server is given as:

        uname -a
        Linux <hostname> 2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:14 EST 2007 x86_64 x86_64 x86_64 GNU/Linux

        Show
        Robin Roos added a comment - - edited My browser is IE version 6.0.2900.2180.xpsp_sp2_gdr.070227-2254 which I take to mean "IE 6.0 SP 2". The bank does not permit Firefox (which intrigues me, as I see Firefox as less of a risk than IE !). The logs (archiva.log) did not show anything when I signed on "successfully" but did have messages that indicated "unsuccessful login" (at which point I got to the unsuccessful login page). n the successful login scenario the archiva.log has no additional entries and I am directed back to the opening page with only three available functions. The server is given as: uname -a Linux <hostname> 2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:14 EST 2007 x86_64 x86_64 x86_64 GNU/Linux
        Hide
        Robin Roos added a comment -

        I've now repeated the exercise with the Opera browser, so this is not an IE-specific issue.

        In the process I've recorded the archiva.log. I've annotated the log with the specific actions I took at various times, each preceded with # for readability. The total log is only 44 lines long.

        A few specific points:

        1. The port I'm using for Archiva on Linux is 9100 (since 8080 was in use). but I used 8080 on Windows. Could this indicate why authentication failse? Are there multiple places where I ought to set 9100?

        2. The log only shows INFO WARN and ERROR levels. Can I invoke DEBUG? I saw no way to configure the logging via the XML files in conf/

        3. The first entry in the log is an ascending number. I'm seeing huge leaps in its value. Perhaps its time-based so I need not be concerned, but if it is a log message id of some sort then something is putting out huge numbers of log messages on a suppressed channel. I point this out in case its useful, although it probably has no significance.

        Finally I will happily run a new version to chase the error, run with DEBUG enabled, or do anything else which might help to resolve this issue. Clearly I am not the only user struggling with this.

        Many thanks, Robin.

        Show
        Robin Roos added a comment - I've now repeated the exercise with the Opera browser, so this is not an IE-specific issue. In the process I've recorded the archiva.log. I've annotated the log with the specific actions I took at various times, each preceded with # for readability. The total log is only 44 lines long. A few specific points: 1. The port I'm using for Archiva on Linux is 9100 (since 8080 was in use). but I used 8080 on Windows. Could this indicate why authentication failse? Are there multiple places where I ought to set 9100? 2. The log only shows INFO WARN and ERROR levels. Can I invoke DEBUG? I saw no way to configure the logging via the XML files in conf/ 3. The first entry in the log is an ascending number. I'm seeing huge leaps in its value. Perhaps its time-based so I need not be concerned, but if it is a log message id of some sort then something is putting out huge numbers of log messages on a suppressed channel. I point this out in case its useful, although it probably has no significance. Finally I will happily run a new version to chase the error, run with DEBUG enabled, or do anything else which might help to resolve this issue. Clearly I am not the only user struggling with this. Many thanks, Robin.
        Hide
        Robin Roos added a comment -

        Attaching the (annotated) log file.

        Show
        Robin Roos added a comment - Attaching the (annotated) log file.
        Hide
        Robin Roos added a comment -

        For reference, I am using Archiva stand-alone (Jetty-based). Arun notes above that he has seen this problem with Tomcat. So it would seem not to be appserver-dependent. I have shown it is not browser-dependent. Could it be OS/JDK-specific? I'm on a 64-bit Linux version using /jdk1.5.0_15.

        Show
        Robin Roos added a comment - For reference, I am using Archiva stand-alone (Jetty-based). Arun notes above that he has seen this problem with Tomcat. So it would seem not to be appserver-dependent. I have shown it is not browser-dependent. Could it be OS/JDK-specific? I'm on a 64-bit Linux version using /jdk1.5.0_15.
        Hide
        Robin Roos added a comment -

        I changed the security policy on IE to accept all cookies regardless of their "compact privicy policy". IE still exhibits the problem - after successful login the user is treated as guest and shown only three functions.

        Show
        Robin Roos added a comment - I changed the security policy on IE to accept all cookies regardless of their "compact privicy policy". IE still exhibits the problem - after successful login the user is treated as guest and shown only three functions.
        Hide
        Robin Roos added a comment -

        Just cheked with Opera again - it is receiving one cookie from Archiva and storing it. The server is "<hostname>.local" and the cookie name is "JSESSIONID". Interestingly Opera shows the expiry date as being "1970-01-01 00:00:00"; since that is the epoch I presume this means "never".

        Is there anything else I can check on my side?

        I'm really keen to get this resolved....

        Show
        Robin Roos added a comment - Just cheked with Opera again - it is receiving one cookie from Archiva and storing it. The server is "<hostname>.local" and the cookie name is "JSESSIONID". Interestingly Opera shows the expiry date as being "1970-01-01 00:00:00"; since that is the epoch I presume this means "never". Is there anything else I can check on my side? I'm really keen to get this resolved....
        Hide
        Robin Roos added a comment -

        I double-checked the URLs used.

        The only difference is the hostname. For the Windows server which accepts my admin credentials and give me all administrative functions the hostname is localhost:8080. For the Linux server, which silently fails on giving the correct admin password, the hostname is <hostname>:9100. The rest of the URLs are the same.

        Show
        Robin Roos added a comment - I double-checked the URLs used. The only difference is the hostname. For the Windows server which accepts my admin credentials and give me all administrative functions the hostname is localhost:8080. For the Linux server, which silently fails on giving the correct admin password, the hostname is <hostname>:9100. The rest of the URLs are the same.
        Hide
        Robin Roos added a comment -

        I've installed continuum-1.0-SNAPSHOT on the same server at port 9200.

        I'm experiencing exactly the same problem, which is not too surprising.

        I've tried "short" admin passwords just in case something was getting truncated, but with no joy.

        I can connect to Archiva and Continuum instances on the same server, but since I cannot log in to them as "admin" I am unable to configure them for use.

        Any and all ideas welcome.

        Show
        Robin Roos added a comment - I've installed continuum-1.0-SNAPSHOT on the same server at port 9200. I'm experiencing exactly the same problem, which is not too surprising. I've tried "short" admin passwords just in case something was getting truncated, but with no joy. I can connect to Archiva and Continuum instances on the same server, but since I cannot log in to them as "admin" I am unable to configure them for use. Any and all ideas welcome.
        Hide
        Robin Roos added a comment -

        This problem IS NOT exhibited by Firefox 2.0.0.12 (and possibly other Firefox versions).

        This problem IS exhibited by IE 6 sp 2, Opera 9.26 and Safari (not sure which version).

        Show
        Robin Roos added a comment - This problem IS NOT exhibited by Firefox 2.0.0.12 (and possibly other Firefox versions). This problem IS exhibited by IE 6 sp 2, Opera 9.26 and Safari (not sure which version).
        Hide
        Arun Nachimuthu added a comment -

        I deployed continuum into the same tomcat instance and even this web application has the same issue. works with firefox and not with IE7

        I will try and use ethreal or other tcp analyser and see the difference in the content exchanged on the wire between browser and server for firefox and ie.

        Show
        Arun Nachimuthu added a comment - I deployed continuum into the same tomcat instance and even this web application has the same issue. works with firefox and not with IE7 I will try and use ethreal or other tcp analyser and see the difference in the content exchanged on the wire between browser and server for firefox and ie.
        Hide
        Robin Roos added a comment -

        Any further update on this? My developers are having to use FireFox (which itslef is no bad thing) in violation of a corporate policy to use only IE.

        Show
        Robin Roos added a comment - Any further update on this? My developers are having to use FireFox (which itslef is no bad thing) in violation of a corporate policy to use only IE.
        Hide
        Maria Odea Ching added a comment -

        I tried this out with IE7 and I was able to login as admin with the correct functions displayed. I was running Archiva 1.0.1 in Ubuntu Linux 7.04, and tried to access it in a Windows machine using IE7 and was not able to replicate this problem. I'll try with IE6 next.

        Show
        Maria Odea Ching added a comment - I tried this out with IE7 and I was able to login as admin with the correct functions displayed. I was running Archiva 1.0.1 in Ubuntu Linux 7.04, and tried to access it in a Windows machine using IE7 and was not able to replicate this problem. I'll try with IE6 next.
        Hide
        Maria Odea Ching added a comment - - edited

        Hmm, it worked for me in IE6. I was still able to login as admin with the correct permissions. The IE6 version I was using was 6.0.2900.2180.xpsp_sp2_qfe.070227-2300. In both tests, I was using the standalone Archiva 1.0.1. The java version installed in the linux machine where Archiva is installed is java 1.5.0_11.

        Btw, you could set the log level to DEBUG in apps/archiva/webapp/WEB-INF/classes/log4j.xml.

        Show
        Maria Odea Ching added a comment - - edited Hmm, it worked for me in IE6. I was still able to login as admin with the correct permissions. The IE6 version I was using was 6.0.2900.2180.xpsp_sp2_qfe.070227-2300. In both tests, I was using the standalone Archiva 1.0.1. The java version installed in the linux machine where Archiva is installed is java 1.5.0_11. Btw, you could set the log level to DEBUG in apps/archiva/webapp/WEB-INF/classes/log4j.xml.
        Hide
        Robin Roos added a comment -

        Hi Maria. I turned on debug, stopped/started Archiva and performed the login attempt as Admin with the correct password. I attach an extract from the log file concerning the login attempt. It would appear that I have a cookie problem:

        94702 [SocketListener0-0] DEBUG org.codehaus.plexus.redback.xwork.util.AutoLoginCookies:default - Remember Me Cookie Not Found: rbkRememberMe
        94702 [SocketListener0-0] DEBUG org.codehaus.plexus.redback.xwork.util.AutoLoginCookies:default - Single Sign On Cookie Not Found: rbkSignon

        Kind regards, Robin.

        Show
        Robin Roos added a comment - Hi Maria. I turned on debug, stopped/started Archiva and performed the login attempt as Admin with the correct password. I attach an extract from the log file concerning the login attempt. It would appear that I have a cookie problem: 94702 [SocketListener0-0] DEBUG org.codehaus.plexus.redback.xwork.util.AutoLoginCookies:default - Remember Me Cookie Not Found: rbkRememberMe 94702 [SocketListener0-0] DEBUG org.codehaus.plexus.redback.xwork.util.AutoLoginCookies:default - Single Sign On Cookie Not Found: rbkSignon Kind regards, Robin.
        Hide
        Robin Roos added a comment -

        Extract from log file - 20 lines covering the login attempt.

        Show
        Robin Roos added a comment - Extract from log file - 20 lines covering the login attempt.
        Hide
        Robin Roos added a comment -

        Screen shot of IE Advanced Privacy Settings showing:

        Override automatic cookie handling: unchecked
        First-party cookies: Accept
        Third-party cookies: Accept
        Always allow session cookies: unchecked (probably doesn't apply unless some cookies are "blocked")

        Show
        Robin Roos added a comment - Screen shot of IE Advanced Privacy Settings showing: Override automatic cookie handling: unchecked First-party cookies: Accept Third-party cookies: Accept Always allow session cookies: unchecked (probably doesn't apply unless some cookies are "blocked")
        Hide
        Stephen Coy added a comment -

        I've observed this problem in both Continuum 1.2.2 and Archiva 1.1.2.

        I tracked it down to the clock on the VM instance running them being wrong by several hours. This causes the applications to send cookies which expire as soon as the browser receives them.

        Show
        Stephen Coy added a comment - I've observed this problem in both Continuum 1.2.2 and Archiva 1.1.2. I tracked it down to the clock on the VM instance running them being wrong by several hours. This causes the applications to send cookies which expire as soon as the browser receives them.
        Hide
        Mario Parra added a comment -

        Does anybody has any update or idea about this?

        I'm still finding this issue with Archiva 1.3.1 and IE7. I think it is a problem with the "rbkSignon" cookie, because its been created on Firefox, but not on IE.

        I'm recommending my users to use Firefox, but the official browser in the company is IE, so it is starting to be a really issue here.

        Here are the logs:

        On Firefox:
        2011-01-20 08:33:42,256 [btpool0-18] DEBUG org.codehaus.plexus.redback.system.DefaultSecuritySystem - User: org.codehaus.plexus.redback.common.ldap.LdapUser@b7e998
        2011-01-20 08:33:42,635 [btpool0-18] DEBUG org.codehaus.plexus.redback.struts2.interceptor.AutoLoginInterceptor - Returning Security Session: org.codehaus.plexus.redback.system.DefaultSecuritySession@47fb00
        2011-01-20 08:33:42,635 [btpool0-18] DEBUG org.codehaus.plexus.redback.struts2.interceptor.AutoLoginInterceptor - User already authenticated.
        2011-01-20 08:33:42,817 [btpool0-18] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - SecureActionInterceptor: processing org.codehaus.plexus.redback.struts2.action.SecurityRedirectAction
        2011-01-20 08:33:42,818 [btpool0-18] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - SecureActionInterceptor: org.codehaus.plexus.redback.struts2.action.SecurityRedirectAction not a secure action
        2011-01-20 08:33:42,818 [btpool0-18] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - not a secure action org.codehaus.plexus.redback.struts2.action.SecurityRedirectAction
        2011-01-20 08:33:42,818 [btpool0-18] DEBUG org.codehaus.plexus.redback.struts2.interceptor.PolicyEnforcementInterceptor - Enforcement: not processing per click security policies.
        2011-01-20 08:33:42,832 [btpool0-18] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - Passing invocation up, result is [security-login-success] on call org.codehaus.plexus.redback.struts2.action.SecurityRedirectAction
        2011-01-20 08:33:42,916 [btpool0-5] DEBUG org.codehaus.plexus.redback.struts2.interceptor.AutoLoginInterceptor - Returning Security Session: org.codehaus.plexus.redback.system.DefaultSecuritySession@47fb00
        2011-01-20 08:33:42,916 [btpool0-5] DEBUG org.codehaus.plexus.redback.struts2.interceptor.AutoLoginInterceptor - User already authenticated.
        2011-01-20 08:33:43,014 [btpool0-5] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - SecureActionInterceptor: processing org.apache.maven.continuum.web.action.GroupSummaryAction
        2011-01-20 08:33:43,014 [btpool0-5] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - SecureActionInterceptor: org.apache.maven.continuum.web.action.GroupSummaryAction not a secure action
        2011-01-20 08:33:43,014 [btpool0-5] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - not a secure action org.apache.maven.continuum.web.action.GroupSummaryAction
        2011-01-20 08:33:43,015 [btpool0-5] DEBUG org.codehaus.plexus.redback.struts2.interceptor.PolicyEnforcementInterceptor - Enforcement: not processing per click security policies.
        2011-01-20 08:33:43,032 [btpool0-5] DEBUG org.codehaus.plexus.redback.rbac.cached.CachedRbacManager - building user permission map
        2011-01-20 08:33:46,880 [btpool0-5] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - Passing invocation up, result is [success] on call org.apache.maven.continuum.web.action.GroupSummaryAction

        On IE7:
        2011-01-20 08:03:21,729 [btpool0-6] DEBUG org.codehaus.plexus.redback.system.DefaultSecuritySystem - User: org.codehaus.plexus.redback.common.ldap.LdapUser@2ea871
        2011-01-20 08:03:22,404 [btpool0-3] DEBUG org.codehaus.plexus.redback.struts2.interceptor.AutoLoginInterceptor - Returning Security Session: org.codehaus.plexus.redback.system.DefaultSecuritySession@1a2ac44
        2011-01-20 08:03:22,404 [btpool0-3] DEBUG org.codehaus.plexus.redback.struts2.interceptor.AutoLoginInterceptor - User already authenticated.
        2011-01-20 08:03:22,404 [btpool0-3] DEBUG org.codehaus.plexus.redback.struts2.interceptor.AutoLoginInterceptor - Login invalidated: signon cookie was removed
        2011-01-20 08:03:22,451 [btpool0-3] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - SecureActionInterceptor: processing org.codehaus.plexus.redback.struts2.action.SecurityRedirectAction
        2011-01-20 08:03:22,451 [btpool0-3] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - SecureActionInterceptor: org.codehaus.plexus.redback.struts2.action.SecurityRedirectAction not a secure action
        2011-01-20 08:03:22,451 [btpool0-3] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - not a secure action org.codehaus.plexus.redback.struts2.action.SecurityRedirectAction
        2011-01-20 08:03:22,451 [btpool0-3] DEBUG org.codehaus.plexus.redback.struts2.interceptor.PolicyEnforcementInterceptor - Enforcement: not processing per click security policies.
        2011-01-20 08:03:22,472 [btpool0-3] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - Passing invocation up, result is [security-login-success] on call org.codehaus.plexus.redback.struts2.action.SecurityRedirectAction
        2011-01-20 08:03:22,545 [btpool0-6] DEBUG org.codehaus.plexus.redback.struts2.interceptor.AutoLoginInterceptor - Returning Security Session: null
        2011-01-20 08:03:22,545 [btpool0-6] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - SecureActionInterceptor: processing org.apache.maven.continuum.web.action.GroupSummaryAction
        2011-01-20 08:03:22,545 [btpool0-6] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - SecureActionInterceptor: org.apache.maven.continuum.web.action.GroupSummaryAction not a secure action
        2011-01-20 08:03:22,545 [btpool0-6] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - not a secure action org.apache.maven.continuum.web.action.GroupSummaryAction
        2011-01-20 08:03:22,545 [btpool0-6] DEBUG org.codehaus.plexus.redback.struts2.interceptor.PolicyEnforcementInterceptor - Enforcement: not processing per click security policies.
        2011-01-20 08:03:22,576 [btpool0-6] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - Passing invocation up, result is [success] on call org.apache.maven.continuum.web.action.GroupSummaryAction

        Show
        Mario Parra added a comment - Does anybody has any update or idea about this? I'm still finding this issue with Archiva 1.3.1 and IE7. I think it is a problem with the "rbkSignon" cookie, because its been created on Firefox, but not on IE. I'm recommending my users to use Firefox, but the official browser in the company is IE, so it is starting to be a really issue here. Here are the logs: On Firefox: 2011-01-20 08:33:42,256 [btpool0-18] DEBUG org.codehaus.plexus.redback.system.DefaultSecuritySystem - User: org.codehaus.plexus.redback.common.ldap.LdapUser@b7e998 2011-01-20 08:33:42,635 [btpool0-18] DEBUG org.codehaus.plexus.redback.struts2.interceptor.AutoLoginInterceptor - Returning Security Session: org.codehaus.plexus.redback.system.DefaultSecuritySession@47fb00 2011-01-20 08:33:42,635 [btpool0-18] DEBUG org.codehaus.plexus.redback.struts2.interceptor.AutoLoginInterceptor - User already authenticated. 2011-01-20 08:33:42,817 [btpool0-18] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - SecureActionInterceptor: processing org.codehaus.plexus.redback.struts2.action.SecurityRedirectAction 2011-01-20 08:33:42,818 [btpool0-18] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - SecureActionInterceptor: org.codehaus.plexus.redback.struts2.action.SecurityRedirectAction not a secure action 2011-01-20 08:33:42,818 [btpool0-18] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - not a secure action org.codehaus.plexus.redback.struts2.action.SecurityRedirectAction 2011-01-20 08:33:42,818 [btpool0-18] DEBUG org.codehaus.plexus.redback.struts2.interceptor.PolicyEnforcementInterceptor - Enforcement: not processing per click security policies. 2011-01-20 08:33:42,832 [btpool0-18] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - Passing invocation up, result is [security-login-success] on call org.codehaus.plexus.redback.struts2.action.SecurityRedirectAction 2011-01-20 08:33:42,916 [btpool0-5] DEBUG org.codehaus.plexus.redback.struts2.interceptor.AutoLoginInterceptor - Returning Security Session: org.codehaus.plexus.redback.system.DefaultSecuritySession@47fb00 2011-01-20 08:33:42,916 [btpool0-5] DEBUG org.codehaus.plexus.redback.struts2.interceptor.AutoLoginInterceptor - User already authenticated. 2011-01-20 08:33:43,014 [btpool0-5] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - SecureActionInterceptor: processing org.apache.maven.continuum.web.action.GroupSummaryAction 2011-01-20 08:33:43,014 [btpool0-5] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - SecureActionInterceptor: org.apache.maven.continuum.web.action.GroupSummaryAction not a secure action 2011-01-20 08:33:43,014 [btpool0-5] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - not a secure action org.apache.maven.continuum.web.action.GroupSummaryAction 2011-01-20 08:33:43,015 [btpool0-5] DEBUG org.codehaus.plexus.redback.struts2.interceptor.PolicyEnforcementInterceptor - Enforcement: not processing per click security policies. 2011-01-20 08:33:43,032 [btpool0-5] DEBUG org.codehaus.plexus.redback.rbac.cached.CachedRbacManager - building user permission map 2011-01-20 08:33:46,880 [btpool0-5] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - Passing invocation up, result is [success] on call org.apache.maven.continuum.web.action.GroupSummaryAction On IE7: 2011-01-20 08:03:21,729 [btpool0-6] DEBUG org.codehaus.plexus.redback.system.DefaultSecuritySystem - User: org.codehaus.plexus.redback.common.ldap.LdapUser@2ea871 2011-01-20 08:03:22,404 [btpool0-3] DEBUG org.codehaus.plexus.redback.struts2.interceptor.AutoLoginInterceptor - Returning Security Session: org.codehaus.plexus.redback.system.DefaultSecuritySession@1a2ac44 2011-01-20 08:03:22,404 [btpool0-3] DEBUG org.codehaus.plexus.redback.struts2.interceptor.AutoLoginInterceptor - User already authenticated. 2011-01-20 08:03:22,404 [btpool0-3] DEBUG org.codehaus.plexus.redback.struts2.interceptor.AutoLoginInterceptor - Login invalidated: signon cookie was removed 2011-01-20 08:03:22,451 [btpool0-3] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - SecureActionInterceptor: processing org.codehaus.plexus.redback.struts2.action.SecurityRedirectAction 2011-01-20 08:03:22,451 [btpool0-3] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - SecureActionInterceptor: org.codehaus.plexus.redback.struts2.action.SecurityRedirectAction not a secure action 2011-01-20 08:03:22,451 [btpool0-3] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - not a secure action org.codehaus.plexus.redback.struts2.action.SecurityRedirectAction 2011-01-20 08:03:22,451 [btpool0-3] DEBUG org.codehaus.plexus.redback.struts2.interceptor.PolicyEnforcementInterceptor - Enforcement: not processing per click security policies. 2011-01-20 08:03:22,472 [btpool0-3] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - Passing invocation up, result is [security-login-success] on call org.codehaus.plexus.redback.struts2.action.SecurityRedirectAction 2011-01-20 08:03:22,545 [btpool0-6] DEBUG org.codehaus.plexus.redback.struts2.interceptor.AutoLoginInterceptor - Returning Security Session: null 2011-01-20 08:03:22,545 [btpool0-6] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - SecureActionInterceptor: processing org.apache.maven.continuum.web.action.GroupSummaryAction 2011-01-20 08:03:22,545 [btpool0-6] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - SecureActionInterceptor: org.apache.maven.continuum.web.action.GroupSummaryAction not a secure action 2011-01-20 08:03:22,545 [btpool0-6] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - not a secure action org.apache.maven.continuum.web.action.GroupSummaryAction 2011-01-20 08:03:22,545 [btpool0-6] DEBUG org.codehaus.plexus.redback.struts2.interceptor.PolicyEnforcementInterceptor - Enforcement: not processing per click security policies. 2011-01-20 08:03:22,576 [btpool0-6] DEBUG org.codehaus.plexus.redback.struts2.interceptor.SecureActionInterceptor - Passing invocation up, result is [success] on call org.apache.maven.continuum.web.action.GroupSummaryAction
        Hide
        Brett Porter added a comment -

        thanks for the data Mario.

        Is Stephen's advice about the clock skew relevant to you here?

        What security level is the browser set at? Does the user see it as an intranet site, or an internet site?

        Show
        Brett Porter added a comment - thanks for the data Mario. Is Stephen's advice about the clock skew relevant to you here? What security level is the browser set at? Does the user see it as an intranet site, or an internet site?
        Hide
        Brett Porter added a comment - - edited

        I saw this myself today. Here's what I had that was being sent:

        • 2 JSESSIONID cookies (path: / and /archiva)
        • rbkRememberMe (path: /archiva)
        • rbkSignon (path: /)

        The server responded clearing both cookies, then setting both cookies on /. It redirects to the redbackRedirect action which sends both, twice, with an empty value and 1970 expiry (4 cookie setting lines). Some other actions continue to unset the two cookies.

        Deleting the above cookies fixed the problem after I logged in again.

        I think it might be the incorrect JSESSIONID, but it may have been the incorrect "remember me" cookie that was never unset.

        Show
        Brett Porter added a comment - - edited I saw this myself today. Here's what I had that was being sent: 2 JSESSIONID cookies (path: / and /archiva) rbkRememberMe (path: /archiva) rbkSignon (path: /) The server responded clearing both cookies, then setting both cookies on /. It redirects to the redbackRedirect action which sends both, twice, with an empty value and 1970 expiry (4 cookie setting lines). Some other actions continue to unset the two cookies. Deleting the above cookies fixed the problem after I logged in again. I think it might be the incorrect JSESSIONID, but it may have been the incorrect "remember me" cookie that was never unset.
        Hide
        Leonardo Penczek added a comment -

        I do not know how to resolve this problem, but i think i found the cause.
        My Firefox was accessing without problems, but my IE wasn't (same problem as above).
        The only difference was that my Firerfox has a rule to skip the web-proxy (it was directly accessing the archiva server) and my IE was using the proxy (because it's configured via WPAD).
        In every machine that i configured to skip the proxy the archiva has returned to work correctly.
        It is an issue with the proxy, it probably was removing/adding/changing some header that archiva is expecting and causing the malfunction.

        Show
        Leonardo Penczek added a comment - I do not know how to resolve this problem, but i think i found the cause. My Firefox was accessing without problems, but my IE wasn't (same problem as above). The only difference was that my Firerfox has a rule to skip the web-proxy (it was directly accessing the archiva server) and my IE was using the proxy (because it's configured via WPAD). In every machine that i configured to skip the proxy the archiva has returned to work correctly. It is an issue with the proxy, it probably was removing/adding/changing some header that archiva is expecting and causing the malfunction.
        Hide
        Olivier Lamy added a comment -

        no more issues fix for 1.3.x except security. Please use 2.x

        Show
        Olivier Lamy added a comment - no more issues fix for 1.3.x except security. Please use 2.x

          People

          • Assignee:
            Olivier Lamy
            Reporter:
            Robin Roos
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: