[jira] [Closed] (MRM-1679) Changing admin password in Continuum using shared external "users" database causes Archiva security workspace to become stale

["Martin Stockhammer (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/MRM-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Stockhammer closed MRM-1679.
-----------------------------------
    Resolution: Fixed

Mentions very old archiva version. Open new issue, if the error still occures with a current version.

> Changing admin password in Continuum using shared external "users" database causes Archiva security workspace to become stale
> -----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: MRM-1679
>                 URL: https://issues.apache.org/jira/browse/MRM-1679
>             Project: Archiva
>          Issue Type: Bug
>          Components: Design, system, Users/Security
>    Affects Versions: 1.4-M3
>         Environment: Windows XP Professional, Firefox 15.0.1, Apache HTTPD 2.2 w/ mod_proxy, Tomcat 7.0.26 (base separated from installation), PostgreSQL v9.2 as external shared database with Continuum 1.4-beta and as Archiva's FileSystem, DataStore, and PM.  Both apps are installed on Tomcat and running as Windows services.
>            Reporter: Chris Harris
>            Priority: Major
>
> I'm sharing the "users" database between Archiva and Continuum.  I switched over to PostgreSQL v9.2 on my laptop to mirror the Archiva/Continuum/PostgreSQL setup I've installed on a server.  I wanted the same password for the admin account as the admin account that's set up on the server, so I changed the password to the admin account using Continuum.
> I was able to then log out and log in with the new password in Continuum.  Upon verifying that I could log in as admin to Archiva with the new password, I discovered that I was not able to log in.
> The remedy was to navigate to C:\apache\tomcat_base_archiva\data\jcr\workspaces and delete the 2 default workspaces "security" & "default".  I know that a workspace's workspace.xml can become stale if something with repository.xml is changed.  Deleting it will prompt Apache Jackrabbit to regenerate a new workspace.xml.  Whether I have to delete BOTH "security" and "default"...I don't know.  Whatever the case may be, that's worked for me.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)