-
Notifications
You must be signed in to change notification settings - Fork 6
Fixing the Archiva Guest User
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.
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.
To fix this, I had to use the Redback security REST API. I used curl
from the terminal.
This took a few steps:
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"
}
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!
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!
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!
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
andGlobal 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.
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
to99999
. - Change
security.policy.password.expiration.enabled
tofalse
. - Click
Save
.
I think that's it.