How to activate an inactive user in Invenio 1.1.6

[fjorba]

From time to time, some users have problems when creating accounts in our Invenios. Most of the times, there is an insidious message that says:

Account 'whatever@example.com' is not yet activated. Try to login with another account. If you think this is not correct, please contact admin@example.com

On Webadmin (Admin Area> WebAccess Admin > Manage Accounts > Manage Accounts) those accounts appear as Active. Sometimes, deleting this offending account and creating another one manually, as admin, works. But now we have one that we cannot activate even with our best efforts. We have desactivated and activated later, we have deleted it and created manually later, etc. To make sure that it is not an email validity problem, we have asked this person to create an account with his personal (gmail) account, hoping that we can change his email later. No way. The message always says that it is 'not yet activated'.

I've tried to follow the code and the sql tables, so I can do something to activate it, but I'm unable to understand where this active/unactive flag is. How can I activate it?

Thanks,

Ferran

PS Hmmm, I'm thinking if it has anything to do with accepting cookies in the browser.

[fjorba]

PS Hmmm, I'm thinking if it has anything to do with accepting cookies in the browser.

Not really. This person has tried it from different computers and different browsers, with the same response.

[fjorba]

Any ideas, please?

[lnielsen]

AFAIR the user activation is controlled via the note field in the user table.

Basically, it can take on the following values:

• 2(pending email confirmation)
• 1(activated)
• 0 (pending administrator confirmation)

I've tracked down the error message you are getting to the page_not_authorized() function. Thus, the following database query fails:

SELECT email FROM user WHERE id=%(uid)s AND note=1

For this query to fail, there are two scenarios:

a) user doesn't exists or the given user does not have a 1 in the note field b) the uid is somehow invalid.

In case of (a) you can quickly verify it by simply querying the database. In case of (b) this is controlled by the getUid() function. This function retrieves the user id from the cookie and one way of getting and invalid uid is if the user refuses cookies.

In order to help more, can you first check if we're dealing with scenario (a) or (b). Also, please let me know the value of CFG_ACCESS_CONTROL_LEVEL_SITE (assuming it is set to 1?)

[fjorba]

Thanks, @lnielsen. Let me answer your questions from last to first:

I understand that the variable you are referring to is not CFG_ACCESS_CONTROL_LEVEL_SITE (defines how open this site is. Use 0 for normal operation of the site, 1 for read-only site (all write operations temporarily closed), 2 for site fully closed) but:

## CFG_ACCESS_CONTROL_LEVEL_ACCOUNTS -- account registration and
## activation policy.  When 0, users can register and accounts are
## automatically activated.  When 1, users can register but admin must
## activate the accounts.  When 2, users cannot register nor update
## their email address, only admin can register accounts.  When 3,
## users cannot register nor update email address nor password, only
## admin can register accounts.  When 4, the same as 3 applies, nor
## user cannot change his login method.  When 5, then the same as 4
## applies, plus info about how to get an account is hidden from the
## login page.

In our case it is 0 (users can register and accounts are automatically activated)

Then, querying the database gives 1:

MariaDB [ddduab]> SELECT email FROM user WHERE id=334814841 AND note=1;
+--------------------------+
| email                    |
+--------------------------+
| his.name@gmail.com       |
+--------------------------+

So the hypotesis b (the uid is somehow invalid) seems more likely. However, this account has been deleted by himself and ourselves several times. This person name is perfectly normal, just plain lower ascii letters and a dot between first and last name, either in his work and personal name. I've also checked that his nickname is unique. The last login field is also valid (2018-06-04 22:10:07)

[lnielsen]

Yes, I meant CFG_ACCESS_CONTROL_LEVEL_ACCOUNTS, sorry :-)

Ok, so then it's definitely getUid() which doesn't return his user id. Is it possible for you to see the value of uid here when he tries to login?

Also it would be useful to know if the execution when he login, ever makes it to the following places:

• https://github.com/inveniosoftware/invenio/blob/maint-1.1/modules/websession/lib/webuser.py#L188
• https://github.com/inveniosoftware/invenio/blob/maint-1.1/modules/websession/lib/webuser.py#L228-L230

@tiborsimko do you possibly have other ideas where it could go wrong

[fjorba]

Ok, so then it's definitely getUid() which doesn't return his user id. Is it possible for you to see the value of uid here when he tries to login?

That's the drama: req is an Apache request, not trivial for me to debug it in a clean environment.

Anyway, I see that it is not obvious for you either. I'll try to log these values in our test installation and see if I can extract something meaningful there. If I get the same error in test, that is!

[lnielsen]

It could even be worse, in the sense this could only happen in your production environment. Definitely, some code in getUid() is not finding his user id I think, but why is the big question. Essentially anything from the browser down to the Invenio python code could be to blame - e.g. browser, plugins, load balancers, proxies, apache, mod_wsgi, python :S

[fjorba]

Finally we have solved it. It turns out that the problem is that the message is wrong. After much reviewing, we found out that the account is perfectly active and is able to do all actions that is allowed to, but when trying to submit, only in that case, Invenio 1.1.6 says that the account is not yet active, when it should say that it wasnt' allowed.

As it happens in those situations, the confusion was incremented by the fact that we thought that the permissions were already set, because we didn't notice that after modifying firewall like role definition in WebAccess Admin > Role Administration > Modify Role needs a confirmation by pressing a button that I didnt see because it was out of the browser window. I discovered that when replicating the role in our test system and seeing that the role wasn't updated.

So, sorry for the noise and thanks for the help!

[lnielsen]

No worries for the noise and thanks for the explanation :-)