Difficult to set admin password about cliopatria HOT 9 OPEN

This continues to be a pain. I'm currently adding a clause to authorized to allow any action so I can add the admin user. Having something better would be good.

from cliopatria.

gniourf says he/she's having trouble reproducing this. I'll try to post a more reproducible set of steps.

from cliopatria.

I wonder if this is caused by some interaction with browser autofill?

from cliopatria.

Having the same issue. Used workaround from @Anniepoo

from cliopatria.

Our users.db is in a sibling directory with the ClioPatria install. this dir is a git repo. I wonder if the issue's something with ownership or permissions?

from cliopatria.

1. Install Cliopatria

   clone ClioPatria into new dir
   ./configure

2. run ClioPatria
   ./run.pl

3. Browse http://localhost:3020/

You are redirected and see a page like

Create administrator

No accounts are available on this server. This form allows for creation of an administrative account that can subsequently be used to create new users.

Add new user

Login
admin
Password
Retype
Permissions ReadWriteAdmin
Create

ClioPatria (version V3.0.0-265-gdd41043)

1. Ignore form, load help/documentation page using the menus
2. Now use menus to look at Admin/Users

EXPECTED: Would be back to the 'create an admin user' form above
OBSERVED: at login screen - but there are no users in the system
and no users.db file in ClioPatria home directory

consequence:
Anyone using ClioPatria compiled into their application has to be sure the very first page that gets loaded is the proper page to set off the admin thing, or they're faced with only being able to fix with above crazy workaround or reinstalling. This is esp. problematic for users who are doing the likely thing of moving cliopatria's root off /

comment:
This is too fragile for a system that needs to be able to be deployed to production.

from cliopatria.

On 10/06/2015 12:48 AM, Anne Ogborn wrote:

ClioPatria (version V3.0.0-265-gdd41043)

Ignore form, load help/documentation page using the menus

Now use menus to look at Admin/Users

EXPECTED: Would be back to the 'create an admin user' form above
OBSERVED: at login screen - but there are no users in the system
and no users.db file in ClioPatria home directory

This indeed reproduces.

consequence:
Anyone using ClioPatria compiled into their application has to be sure
the very first page that gets loaded is the proper page to set off the
admin thing, or they're faced with only being able to fix with above
crazy workaround or reinstalling. This is esp. problematic for users who
are doing the likely thing of moving cliopatria's root off /

Just visiting / (or the moved entry location) suffices. At least in theory
we could do the redirect-to-create-admin-if-there-are-no-users from more
places. Possibly also from Admin/Users and Login?

comment:
This is too fragile for a system that needs to be able to be deployed to
production.

How come? It is just part of the installation procedure. I guess it
mostly goes wrong if you wipe the server including users.db and re-install
it while you are using some bookmark to access it that doesn't make you
visit the initial page. Is that what happens? Why? I see two main
reasons to re-install the application:

1. You messed up the RDF store. If it is so bad that Repository/Clear
   repository
   no longer does the job:

   • Stop the server
   • Delete the RDF-Store directory
   • Restart the server

2. You messed up the cpacks

   • Delete config-enabled and cpack directories. If you did real
     configuration,
     just delete config-enables/010-packs.pl
   • re-run configure.
   • re-install required cpacks.

   Cheers --- Jan

from cliopatria.

consequence...

How come? It is just part of the installation procedure. I guess it
mostly goes wrong if you wipe the server including users.db and re-install
it while you are using some bookmark to access it that doesn't make you
visit the initial page. Is that what happens? Why? I see two main
reasons to re-install the application..

We reinstall fresh on the test server for the daily build, that happens in a fresh docker container.

That this step is difficult to automate doesn't help.

It's not that unusual to reinstall for this or that reason during development.

It's not like this is the end of the world, but it's a pretty fragile system. If you don't get it right the first time you have lost your chance and have to install again.

We remove RDF-store many times a day in development.

What it needs to do is say 'hey, I don't have an admin user - I'll present the 'make an admin user' page.

If you're developing an application compiled in with ClioPatria often the sequence goes something like this:

Pull changes
visit some page
fiddle around debugging
realize there's something incorrectly asserted and you need to muck with the db - go to look at the db, surprise, you're locked out.

Jan, maybe we should get on skype and work out a useable system on voice? I suspect there's confusion here. Maybe it needs extra documentation, or maybe a fix.

from cliopatria.

atop all this there's some issue that removing RDF-Store (or something else we're doing that might much with cpacks, etc but does NOT wipe users.db ) is breaking the passwords. So this further increases the urgency of this

from cliopatria.