Page MenuHomePhabricator

Can't verify email address if user doesn't have view policy for any space
Closed, DuplicatePublic

Description

For one of our Phabricator installs we need security/view policies to be very tight, so users don't have view policy for any space (not even a default one) before I grant them manually (join them to project/group that has view policy for space).

After more then a few users joined, I noticed many users that don't have their email verified or verifying them eventually with some delay.

I become suspicious and after a phone call with one user that I wanted to verify email ASAP, I noticed that he indeed clicked verify email link from welcome mail, but nothing happened.

I think this could cause a lot of problems regarding email notifications, considering a change from 2017 Week 7 (Late February).

Reproduction steps

  • Login as user with Administrator rights
  • Create default space (if doesn't exists)
  • Limit that space "Visible to" policy to Administrators
  • Open another browser or session and register as new user
  • Upon receiving "[Phabricator] Email Verification" email, click on the link provided

Expected results:

  • Email verified for that user

Actual result:

  • Email still not verified, just message that says
No Access to Spaces	
This install uses spaces to organize objects, but your account does not have access to any spaces.

Ask someone to give you access to a space so you can view and create objects.

Also probably unrelated bug in the frontend, the "user" icon in left top bar menu is yellow and when clicked it contains string "undefined" (as can be seen on screenshot)

Version Information

phabricator 65de9e9f5e7f2ecc018ff300e13227d77ea342da (Thu, Mar 16)
arcanist    3b6b523c2b236e3724a1e115f126cb6fd05fa128 (Feb 18 2017)
phutil      13a200ca7621ab2b48a0c395f52f8c4411bbc686 (Sat, Mar 4)

Event Timeline

bbrdaric created this task.Mar 20 2017, 2:41 PM

Instead of using open registration, can you invite users instead and immediately add them to spaces so this doesn't happen? Why are you allowing open registration if all registration must be coordinated with an administrator anyway?

chad added a subscriber: chad.Mar 21 2017, 1:14 AM

This sounds like the expected result to me. Even if they did get verified, they would immediately hit the same "No Access" dialog again.

Why should verifying email address depend on any space view policy?

@epriestley Inviting users could be a good idea, but I want allow "Project administrators" group to do that.

I saw "Can Create (non-bot) Users" policy in People application and thought this would be a good solution, but it seems that policy has no effect or I don't understand how it works. Even if I set "All Users" for that policy, only Administrators have "Create New User" link and User administration section in left sidebar. What am I doing wrong here?

@chad For me that's not expected result. They should be verified no matter access policy or some error message displayed. "No Access" dialog is expected and that's okay.

"Can Create (Non-Bot) Users" is a fake permission for Phacility SAAS disguised as a real permission. You must always have that permission and be an administrator to create users: that is, it can only be used to reduce the set of administrators who have permission to create users. In the Phacility SAAS cluster, we set this permission to "No One".

Can you just make all "Project Administrators" into real administrators? What's the technical reason that "Project Administrators" and "Real Administrators" are distinct groups, if you want "Project Administrators" to be able to invite users?

Oh, I see...so, no luck there...but this would be a great option if it worked the way I initially understood.

I don't want to make all "Project Administrators" into real administrators because they generally aren't technical stuff and are easily confused with various administrative options. I am pretty sure they would go exploring and change some policy or something else.

Is it just possible to fix this email verfication bug so everything works as expected or you don't think this is a bug?

Is it possible to disable email verification or force verify email validation for current users? I really see no other option...

I don't really consider this behavior a bug, because this (users registering into zero spaces) isn't really a supported workflow. The menu rendering is less ambiguously a bug, but I'd likely fix it by just hiding the menu in this state, and that won't address your issue. And it doesn't cause any problems unless you get into this questionable state in the first place, so cleaning it up is difficult to prioritize.

Your workflow looks like this, right?

  • Users register, but can't do anything with their accounts.
  • Separately, users email a project administrator to get access (they know to do this via some out-of-band channel?).
  • The project administrator grants them access to projects or directly to spaces.
  • The project administrator emails them back to let them know they can continue.

This isn't a workflow we want to support in a first-class way because it's pretty clumsy. A version of this workflow we'd be more open to supporting might look more like this, per above:

  • Project administrators invite users and add them to the right spaces/projects at the same time, so things are already set up by the time they log in.

This is better for users and for administrators (fewer steps for everyone), and doesn't put users into the "no access to spaces" state. Some changes we might consider to support this workflow:

  • Provide a real "Can Create Users" permission or a narrower "Can Invite Users" permission.
  • Allow you to immediately add new accounts to projects during the invite/create workflows.
  • Allow you to lock or restrict workflows you have material concerns about (like application policy/config).
  • If the text on the "no access to spaces" dialog made you think that this is a supported workflow which we expect users to encounter during registration, we could consider changing it to make it more clear that this state is an error state.

But these are difficult to prioritize because they would essentially impact only one install (yours) today.

Another supportable workflow might be:

  • When users log in for the first time, they get access to into a common/sandbox space which doesn't have anything interesting, but allows them to set up their accounts and guides them toward requesting greater access.

I'm not sure what the technical barriers to implementing this workflow are in your environment.


Is it possible to disable email verification

No, and I don't plan to provide any options to do this, at least not without first seeing stronger use cases impacting a wider range of installs and workflows.

force verify email validation for current users

  • You can force-verify an email with bin/auth verify <email>
  • If a user clicks an email invite link to register, their email is automatically verified.
  • If a user registers with an OAuth provider that has the "Trust Email Addresses" flag checked, their email is automatically verified.

I am pretty sure they would go exploring and change some policy or something else.

What specific policy changes are you concerned that they'll make? The only policy changes that administrators naturally get access to that non-administrators don't have are are application policies. Just like normal users, administrators are still bound by policy controls, and can not edit anything they couldn't otherwise edit as normal users, unless the policy for editing it is "Administrators".

Administrators also get access to Config, but they normally can't do much damage there since all the major stuff is locked to the CLI anyway.

Your workflow looks like this, right?

  • Users register, but can't do anything with their accounts.
  • Separately, users email a project administrator to get access (they know to do this via some out-of-band channel?).
  • The project administrator grants them access to projects or directly to spaces.
  • The project administrator emails them back to let them know they can continue.

Yes, more or less, something like this.

A version of this workflow we'd be more open to supporting might look more like this, per above:

  • Project administrators invite users and add them to the right spaces/projects at the same time, so things are already set up by the time they log in.

This is better for users and for administrators (fewer steps for everyone), and doesn't put users into the "no access to spaces" state. Some changes we might consider to support this workflow:

  • Provide a real "Can Create Users" permission or a narrower "Can Invite Users" permission.
  • Allow you to immediately add new accounts to projects during the invite/create workflows.
  • Allow you to lock or restrict workflows you have material concerns about (like application policy/config).
  • If the text on the "no access to spaces" dialog made you think that this is a supported workflow which we expect users to encounter during registration, we could consider changing it to make it more clear that this state is an error state.

But these are difficult to prioritize because they would essentially impact only one install (yours) today.

This might be acceptable, especially with, as you say real "Can Create Users" permission or a narrower "Can Invite Users" permission. This is something I would really like to see because it would solve all my problems at once and simplify workflow dramatically, and I wouldn't have to give Admin rights to random users just to invite other users.

Another supportable workflow might be:

  • When users log in for the first time, they get access to into a common/sandbox space which doesn't have anything interesting, but allows them to set up their accounts and guides them toward requesting greater access.

I'm not sure what the technical barriers to implementing this workflow are in your environment.

I think this approach would confuse new users because they would try to start doing something right away and I would need to explain them to wait until we put them in appropriate space.

I really like the idea putting them in space during / right after user creation.


Is it possible to disable email verification

No, and I don't plan to provide any options to do this, at least not without first seeing stronger use cases impacting a wider range of installs and workflows.

force verify email validation for current users

  • You can force-verify an email with bin/auth verify <email>
  • If a user clicks an email invite link to register, their email is automatically verified.
  • If a user registers with an OAuth provider that has the "Trust Email Addresses" flag checked, their email is automatically verified.

Thanks, but where can I see user email addresses? After users are approved, there is no email address displayed anywhere. I feel this should be in the user list (in the People app). I tried bin/accountadmin, bin/people and conduit but without success...

Just noticed one more quirky thing about users with no view policy for any space. They can't log out and they get one more "No Access to Spaces" message in the modal. Just like email verification, I don't understand why log out should depend on space view policy.