Skip to content

Fixing the Archiva Guest User

Ben Heasly edited this page Feb 19, 2016 · 2 revisions

Once upon a time, at our brainard-archiva Archiva server, the guest user got messed up. This broke guest access from the Web UI and for REST API.

I think I fixed the problem by deleting the guest user and recreating it. Here's some more detail.

What Happened

By default, Archiva requires password resets every 90 days. We didn't want this in the first place, but it happened once, and it was too late.

Even the guest account was affected by the reset cycle. This is surely an Archiva bug. guest should not have any password at all, so it should have been exempt from the reset cycle.

I was able to set a new password for the guest in the normal way through the admin Web UI. But this is not really what we want. We don't want a new password, we want the un-password. Because of length constraints on normal passwords, it was impossible to specify the un-password through the Web UI or the REST API.

The Fix

To fix this, I had to use the Redback security REST API. I used curl from the terminal.

This took a few steps:

Get the guest as JSON

To work with the REST API, we want to get the JSON representation of the guest

curl -v -u admin:*** http://52.32.77.154/restServices/redbackServices/userService/getUser/guest

This gave me the following JSON. I pretty-printed it and saved it in a file guest.json:

{
  "username": "guest",
  "fullName": "Guest",
  "email": "",
  "validated": false,
  "locked": false,
  "password": null,
  "passwordChangeRequired": false,
  "permanent": true,
  "confirmPassword": null,
  "timestampAccountCreation": "Fri, 19 Feb 2016 17:29:12 +0000 - 18 minutes ago",
  "timestampLastLogin": null,
  "timestampLastPasswordChange": "Fri, 19 Feb 2016 17:29:12 +0000 - 18 minutes ago",
  "previousPassword": null,
  "assignedRoles": null,
  "readOnly": false,
  "userManagerId": "jdo"
}

Make the guest Deletable

By default, it's impossible to delete the guest because it's permanent. But we can change that. I updated guest.json to make it so:

{
  "username": "guest",
  "fullName": "Guest",
  "email": "",
  "validated": false,
  "locked": false,
  "password": null,
  "passwordChangeRequired": false,
  "permanent": false,
  "confirmPassword": null,
  "timestampAccountCreation": "Fri, 19 Feb 2016 17:29:12 +0000 - 18 minutes ago",
  "timestampLastLogin": null,
  "timestampLastPasswordChange": "Fri, 19 Feb 2016 17:29:12 +0000 - 18 minutes ago",
  "previousPassword": null,
  "assignedRoles": null,
  "readOnly": false,
  "userManagerId": "jdo"
}

Then I POST-ed the JSON to the updateUser endpoint:

curl -v -u admin:*** -X POST -d @guest.json http://52.32.77.154/restServices/redbackServices/userService/updateUser --header "Content-Type:application/json"

This returned a 200 "Success" status. Cool!

Delete the guest

Now we can delete the old, messed up guest:

curl -v -u admin:*** http://52.32.77.154/restServices/redbackServices/userService/deleteUser/guest

This also returned a 200 "Success" status. Getting there!

Make a New guest

Now we can make a fresh guest with no password.

curl -v -u admin:*** http://52.32.77.154/restServices/redbackServices/userService/createGuestUser

Another 200 "Success". We did it!

Fix up guest Permissions.

The new guest started out with no permissions. But we can fix this through the normal admin Web UI:

  • Go to the Web UI and log in as admin.
  • On the left navigate to Users -> Manage -> Edit -> guest.
  • Click on Edit Roles.
  • Check Guest and Global Repository Observer.
  • Click Update.

This should do it. We should finally have a fresh guest that works as we want.

You can check this by logging out from the Web UI and trying to Search and Browse. You should be able to find artifacts.

Prevention

We would like to avoid this situation in the future. We can do this by turning off password resets altogether. This is fine for us because we didn't care about resets in the first place.

To turn off password reset:

  • Go to the Web UI and log in as admin.
  • On the left navigate to Users -> Users Runtime Configuration -> Properties.
  • Navigate to page 3.
  • Change security.policy.password.expiration.days to 99999.
  • Change security.policy.password.expiration.enabled to false.
  • Click Save.

I think that's it.