After successful admin login archiva reacts as if user is guest

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!

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

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

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.

Attaching the (annotated) log file.

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.

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.

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....

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.

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.

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).

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.

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.

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.

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.

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.

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

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")

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.

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

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?

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.

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.