Mark Users as active on Registration

By: Paul Frame user 07 Mar 2016 at 4:39 p.m. CST

13 Responses
Paul Frame gravatar
This should be a relatively easy one. Users that register are not immediately being marked as active. They are unable to login until I search for their user and press update so that gluu marks them as active. So, following other tickets on these support forums, I used the sample registration script found here https://www.gluu.org/docs/customize/sample-user-registration-script.py And modified the preRegistration method (using proper indentation), so that it would do "user.setStatus(GluuStatus.ACTIVE)". But when I enable this custom script.. registration doesn't work at all. Just keeps me on same page. wrapper.log INFO | jvm 1 | 2016/03/07 22:36:17 | sourceId=null[severity=(ERROR 2), summary=(Failed to register new user. Please make sure you are not registering a duplicate account or try another username.), detail=(Failed to register new user. Please make sure you are not registering a duplicate account or try another username.)]
None
closed

Answers

By Aliaksandr Samuseu staff 08 Mar 2016 at 5:16 a.m. CST

Copy
Aliaksandr Samuseu gravatar
Hi, Paul. Could you provide your modified registration script for us to check (if you don't have access to attachments please use some 3rd-party file sharing service, pastebin.com to name one) Regards, Alex.

By Mohib Zico Account Admin 08 Mar 2016 at 7:35 a.m. CST

Copy
Mohib Zico gravatar
Paul, Check [this](https://support.gluu.org/identity-management/activate-self-registered-user-2527) ticket.

By Yuriy Movchan staff 08 Mar 2016 at 8:05 a.m. CST

Copy
Yuriy Movchan gravatar
gluu-server by default don't allow to log in new users until admin explicitly allow them login. But it has flexible tool to to customize this behavior. In order to active users by default you should log into oxTrust (identity) as administrator. And do next: - Open "Manage Custom Scripts" - Select "User Registration" tab - Change property "enable_user" value from 'false' to 'true' - Select "Enabled" checkbox - Click "Update" button - Try to register new user after 30 seconds. During this time identity should load this script. This is default simple custom registration script. You can update it if needed.

By Paul Frame user 08 Mar 2016 at 9:36 a.m. CST

Copy
Paul Frame gravatar
@Aliaksandr http://pastebin.com/5bw11EV9 @Yuriy "Change property "enable_user" value from 'false' to 'true'" This is code, not a list of dropdown boxes. Which method is this in? @Mohib I have become quite familiar with the ins and outs of opendj and the gluuStatus Active flag (as seen here https://support.gluu.org/other/import-people-not-marked-as-active-2348) I'm just trying to accomplish this via the custom python script so that the user is set as active during the registration process.

By Mohib Zico Account Admin 10 Mar 2016 at 7:46 a.m. CST

Copy
Mohib Zico gravatar
>> I'm just trying to accomplish this via the custom python script so that the user is set as active during the registration process. You don't need python script in 2.4.2 version. You can just enable/disable it with oxTrust GUI.

By Aliaksandr Samuseu staff 10 Mar 2016 at 12:26 p.m. CST

Copy
Aliaksandr Samuseu gravatar
Hi, Paul. Sorry for delay. It seems this script you got from github is outdated a bit. For 2.4.2 your best option is to use pre-packaged script that comes with it. In case you over-wrote it already, I'm attaching the one copied from my test instance. Please also note that, as Zico has mentioned, the current version does use script configuration parameter controlling whether or not user will be active after registration. Check attached screenshot showing how you declare it.
reg-script.jpg reg-script_MzXhTTx.txt

By Paul Frame user 10 Mar 2016 at 12:48 p.m. CST

Copy
Paul Frame gravatar
Thank you for the responses. Good to know that 2.4.2 finally has a dropdown for that option. We barely upgraded to 2.4.1 and I'm fairly scared that an update will break everything again, but I'm going to make an attempt in a test environment.

By Aliaksandr Samuseu staff 10 Mar 2016 at 1:16 p.m. CST

Copy
Aliaksandr Samuseu gravatar
You should try to use this one anyway. `diff` shows that aside of importing `GluuStatus` and adding several strings that manipulate it nothing was changed. Unless this structure hadn't existed before 2.4.2, there shouldn't be any issues with using the script in 2.4.1

By Paul Frame user 10 Mar 2016 at 2:23 p.m. CST

Copy
Paul Frame gravatar
I tested the script you gave me as is and it is giving me the same error that my script was giving.

By Aliaksandr Samuseu staff 10 Mar 2016 at 2:27 p.m. CST

Copy
Aliaksandr Samuseu gravatar
> I tested the script you gave me as is and it is giving me the same error that my script was giving. Are you sure you don't actually "registering a duplicate account", as it claims? Also, could you try to provide it some very simple username ("aaaaa") for a test? A screenshot of the registration page would be helpful too. Did you modify list of registration form's attributes on the "Configuration->Manage registration" page?

By Paul Frame user 10 Mar 2016 at 3:08 p.m. CST

Copy
Paul Frame gravatar
I'm certain that the account doesn't exist. I attempted to create a user named aaaaa, who I'm sure does not exist in the system. Just loops me back to the same page without an error and wrapper.log gives that same error. Only changes are some mild css changes and we have a simple peice of javascript that automatically fills in the display name field with a combination of their first and last name. The manage registration page is untouched.

By Aliaksandr Samuseu staff 10 Mar 2016 at 3:37 p.m. CST

Copy
Aliaksandr Samuseu gravatar
> I'm certain that the account doesn't exist I can't reproduce it in my 2.4.2 instance. Can it be some kind of bug of 2.4.1? What is your full package name/version? Could you also disable capcha on the "Configuration->Manage registration" page and try again?

By Aliaksandr Samuseu staff 10 Mar 2016 at 3:44 p.m. CST

Copy
Aliaksandr Samuseu gravatar
You could also try to use debuggin inlets like print "Debugging inlet #1" throughout default registration script to figure out whether or not workflow even reaches it. A good place to start is `init` function. You can check the output from the scripts in either `oxauth_script.log` or `oxtrust_script.log` (most likely the later). May be you'll be able to narrow it down to a particular function/instruction when it fails that way.

Post an answer