Skip to content
This repository has been archived by the owner on Nov 14, 2018. It is now read-only.

Juliabox campus email verification #339

Open
barche opened this issue Dec 12, 2015 · 8 comments
Open

Juliabox campus email verification #339

barche opened this issue Dec 12, 2015 · 8 comments

Comments

@barche
Copy link
Contributor

barche commented Dec 12, 2015

Hi all,

We would like to roll out a JuliaBox installation on our campus, with the possibility to limit usage to white-listed email domains (e.g. only email addresses from our official domain). Is there any way to configure this on the existing JuliaBox, or does it require writing a new auth module?

Ideally, a mail should be sent to a user when registering, with a validation link to activate the account.

I'd be willing to put in the effort to write something, but I could use some pointers on where to get started. For example, I noticed the code contains references to a pending_activation flag, but it seems to be cleared automatically based on load, is that correct? I was thinking it might be possible to also couple the activation to a click on the link in the email, but I'm not sure is the pending_activation flag can be reused for that.

Kind regards,

Bart

@tanmaykm
Copy link
Member

Hi Bart, yes that will involve writing a new auth module in the current scheme.

JuliaBox currently has a activation process, but it it used only for rate-limiting the registration process (protection against temporary surges). It sends out an activation-email and auto-activates users based on configured rates. It would also be possible to do what you need by externalizing the activation process as a module and let custom rules to be built into it.

@barche
Copy link
Contributor Author

barche commented Dec 13, 2015

OK, so regarding the attributes of the users, I could define a new activation_code value, something like "EMAIL", and this would then not interfere with the rate-limiting version that seems to use AUTO as code, right?

Also, I think I may just allow setting a password directly, so what would be a good place to store the hash?

@tanmaykm
Copy link
Member

The pending_activation flag is part of the activation process, and can be reused if you take the latter alternative.

@tanmaykm
Copy link
Member

Yes. You could use new activation code for that and a new E-mail template to go with it.

Having your own password database will require a new auth plugin.

@tanmaykm
Copy link
Member

Related: post authorization hooks provided in #381

@barche
Copy link
Contributor Author

barche commented Sep 26, 2016

I took a look at the post authorization hooks, and I think I could fairly easily implement what I need using that. I would like to do the following in a post-auth plugin:

  1. Ask user for campus email
  2. Send a random code to that email address if it is whitelisted
  3. Ask user to enter the sent code
  4. Check if the code matches and if so authorize the user

The plugin would be configured with a whitelist of addresses and/or domains in jbox.user. The advantage of this is that it can happen after the normal auth procedure and no manual password bookkeeping is needed, as would be with a full-blown auth plugin.

I can't figure out how to wait for the response in step 1, however. I can use handler.render to get the email form to show, but my process_user_id function doesn't wait around for the user response. Is there a way to make it wait, or am I going about this the wrong way?

barche added a commit to barche/JuliaBox that referenced this issue Oct 3, 2016
@barche
Copy link
Contributor Author

barche commented Oct 3, 2016

@tanmaykm I have a first version working in my fork. I'll add some docs and submit a pull request once properly tested. I realized that waiting was not a good option, so now I use a new table in the database as intermediate step.

@tanmaykm
Copy link
Member

tanmaykm commented Oct 4, 2016

👍 @barche. Keeping the intermediate step in the table is much better. Thanks!

barche added a commit to barche/JuliaBox that referenced this issue Oct 7, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants