2024-04-24 11:20:17 -07:00
|
|
|
import json
|
2024-03-19 09:30:20 -07:00
|
|
|
import uuid
|
2024-03-19 11:32:36 -07:00
|
|
|
from datetime import datetime, timedelta
|
2024-10-25 16:55:34 -04:00
|
|
|
from urllib.parse import unquote
|
2016-01-19 15:50:31 +00:00
|
|
|
|
2024-03-19 11:32:36 -07:00
|
|
|
from flask import (
|
|
|
|
|
abort,
|
|
|
|
|
current_app,
|
2024-04-25 13:48:14 -07:00
|
|
|
flash,
|
2024-03-19 11:32:36 -07:00
|
|
|
redirect,
|
|
|
|
|
render_template,
|
|
|
|
|
request,
|
|
|
|
|
session,
|
|
|
|
|
url_for,
|
|
|
|
|
)
|
2016-10-13 17:05:37 +01:00
|
|
|
from flask_login import current_user
|
2016-01-22 17:24:14 +00:00
|
|
|
|
2024-05-09 14:04:30 -07:00
|
|
|
from app import redis_client, user_api_client
|
2015-12-01 13:23:54 +00:00
|
|
|
from app.main import main
|
2024-05-08 11:30:51 -07:00
|
|
|
from app.main.forms import (
|
2016-03-02 15:25:04 +00:00
|
|
|
RegisterUserForm,
|
2018-02-20 11:22:17 +00:00
|
|
|
RegisterUserFromOrgInviteForm,
|
2024-03-19 09:30:20 -07:00
|
|
|
SetupUserProfileForm,
|
2016-03-02 15:25:04 +00:00
|
|
|
)
|
2024-03-19 11:32:36 -07:00
|
|
|
from app.main.views import sign_in
|
2017-11-10 12:35:21 +00:00
|
|
|
from app.main.views.verify import activate_user
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
from app.models.user import InvitedOrgUser, InvitedUser, User
|
2024-04-24 11:20:17 -07:00
|
|
|
from app.utils import hide_from_search_engines, hilite
|
2024-05-20 12:09:49 -07:00
|
|
|
from app.utils.user import is_gov_user
|
2015-12-01 13:23:54 +00:00
|
|
|
|
2016-01-11 15:17:00 +00:00
|
|
|
|
2023-08-25 09:12:23 -07:00
|
|
|
@main.route("/register", methods=["GET", "POST"])
|
2020-05-26 17:39:25 +01:00
|
|
|
@hide_from_search_engines
|
2016-01-08 15:12:14 +00:00
|
|
|
def register():
|
2016-05-04 13:01:55 +01:00
|
|
|
if current_user and current_user.is_authenticated:
|
2023-08-25 09:12:23 -07:00
|
|
|
return redirect(url_for("main.show_accounts_or_dashboard"))
|
2016-01-22 17:24:14 +00:00
|
|
|
|
2016-01-28 16:36:36 +00:00
|
|
|
form = RegisterUserForm()
|
2015-12-01 13:23:54 +00:00
|
|
|
if form.validate_on_submit():
|
2016-07-12 11:53:30 +01:00
|
|
|
_do_registration(form, send_sms=False)
|
2023-08-25 09:12:23 -07:00
|
|
|
return redirect(url_for("main.registration_continue"))
|
2016-03-09 15:12:33 +00:00
|
|
|
|
2023-08-25 09:12:23 -07:00
|
|
|
return render_template("views/register.html", form=form)
|
2016-03-02 15:25:04 +00:00
|
|
|
|
|
|
|
|
|
2023-08-25 09:12:23 -07:00
|
|
|
@main.route("/register-from-org-invite", methods=["GET", "POST"])
|
2024-05-06 12:15:57 -07:00
|
|
|
# TODO This is deprecated, we are now handling invites in the
|
2024-05-07 13:58:59 -07:00
|
|
|
# login.gov workflow. Leaving it here until we write the new
|
|
|
|
|
# org registration.
|
2018-02-19 16:53:29 +00:00
|
|
|
def register_from_org_invite():
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
invited_org_user = InvitedOrgUser.from_session()
|
2018-02-19 16:53:29 +00:00
|
|
|
if not invited_org_user:
|
|
|
|
|
abort(404)
|
|
|
|
|
|
|
|
|
|
form = RegisterUserFromOrgInviteForm(
|
|
|
|
|
invited_org_user,
|
|
|
|
|
)
|
2023-08-25 09:12:23 -07:00
|
|
|
form.auth_type.data = "sms_auth"
|
2018-02-19 16:53:29 +00:00
|
|
|
|
|
|
|
|
if form.validate_on_submit():
|
2023-08-25 09:12:23 -07:00
|
|
|
if (
|
|
|
|
|
form.organization.data != invited_org_user.organization
|
|
|
|
|
or form.email_address.data != invited_org_user.email_address
|
|
|
|
|
):
|
2018-02-19 16:53:29 +00:00
|
|
|
abort(400)
|
2023-08-25 09:12:23 -07:00
|
|
|
_do_registration(
|
|
|
|
|
form,
|
|
|
|
|
send_email=False,
|
|
|
|
|
send_sms=True,
|
|
|
|
|
organization_id=invited_org_user.organization,
|
|
|
|
|
)
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
invited_org_user.accept_invite()
|
2018-02-19 16:53:29 +00:00
|
|
|
|
2023-08-25 09:12:23 -07:00
|
|
|
return redirect(url_for("main.verify"))
|
|
|
|
|
return render_template(
|
|
|
|
|
"views/register-from-org-invite.html",
|
|
|
|
|
invited_org_user=invited_org_user,
|
|
|
|
|
form=form,
|
|
|
|
|
)
|
2018-02-19 16:53:29 +00:00
|
|
|
|
|
|
|
|
|
2023-07-12 12:09:44 -04:00
|
|
|
def _do_registration(form, send_sms=True, send_email=True, organization_id=None):
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
user = User.from_email_address_or_none(form.email_address.data)
|
|
|
|
|
if user:
|
2018-02-19 16:53:29 +00:00
|
|
|
if send_email:
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
user.send_already_registered_email()
|
2023-08-25 09:12:23 -07:00
|
|
|
session["expiry_date"] = str(datetime.utcnow() + timedelta(hours=1))
|
|
|
|
|
session["user_details"] = {"email": user.email_address, "id": user.id}
|
2018-02-19 16:53:29 +00:00
|
|
|
else:
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
user = User.register(
|
|
|
|
|
name=form.name.data,
|
|
|
|
|
email_address=form.email_address.data,
|
|
|
|
|
mobile_number=form.mobile_number.data,
|
|
|
|
|
password=form.password.data,
|
|
|
|
|
auth_type=form.auth_type.data,
|
|
|
|
|
)
|
|
|
|
|
|
2016-03-15 16:58:26 +00:00
|
|
|
if send_email:
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
user.send_verify_email()
|
2016-03-17 13:07:52 +00:00
|
|
|
|
|
|
|
|
if send_sms:
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
user.send_verify_code()
|
2023-08-25 09:12:23 -07:00
|
|
|
session["expiry_date"] = str(datetime.utcnow() + timedelta(hours=1))
|
|
|
|
|
session["user_details"] = {"email": user.email_address, "id": user.id}
|
2023-07-12 12:09:44 -04:00
|
|
|
if organization_id:
|
2023-08-25 09:12:23 -07:00
|
|
|
session["organization_id"] = organization_id
|
2016-03-17 13:07:52 +00:00
|
|
|
|
|
|
|
|
|
2023-08-25 09:12:23 -07:00
|
|
|
@main.route("/registration-continue")
|
2016-03-17 13:07:52 +00:00
|
|
|
def registration_continue():
|
2023-08-25 09:12:23 -07:00
|
|
|
if not session.get("user_details"):
|
|
|
|
|
return redirect(url_for(".show_accounts_or_dashboard"))
|
2024-03-19 09:30:20 -07:00
|
|
|
else:
|
|
|
|
|
raise Exception("Unexpected routing in registration_continue")
|
|
|
|
|
|
2024-03-18 13:50:23 -04:00
|
|
|
|
2024-05-10 07:51:32 -07:00
|
|
|
def get_invite_data_from_redis(state):
|
|
|
|
|
|
2024-06-07 09:07:42 -07:00
|
|
|
invite_data = json.loads(redis_client.get(f"invitedata-{state}"))
|
|
|
|
|
user_email = redis_client.get(f"user_email-{state}").decode("utf8")
|
|
|
|
|
user_uuid = redis_client.get(f"user_uuid-{state}").decode("utf8")
|
|
|
|
|
invited_user_email_address = redis_client.get(
|
2024-05-10 07:51:32 -07:00
|
|
|
f"invited_user_email_address-{state}"
|
|
|
|
|
).decode("utf8")
|
|
|
|
|
return invite_data, user_email, user_uuid, invited_user_email_address
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def put_invite_data_in_redis(
|
|
|
|
|
state, invite_data, user_email, user_uuid, invited_user_email_address
|
|
|
|
|
):
|
|
|
|
|
ttl = 60 * 15 # 15 minutes
|
|
|
|
|
|
2024-06-20 11:50:51 -07:00
|
|
|
redis_client.set(f"invitedata-{state}", json.dumps(invite_data), ex=ttl)
|
|
|
|
|
redis_client.set(f"user_email-{state}", user_email, ex=ttl)
|
|
|
|
|
redis_client.set(f"user_uuid-{state}", user_uuid, ex=ttl)
|
|
|
|
|
redis_client.set(
|
2024-05-10 07:51:32 -07:00
|
|
|
f"invited_user_email_address-{state}",
|
|
|
|
|
invited_user_email_address,
|
|
|
|
|
ex=ttl,
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def check_invited_user_email_address_matches_expected(
|
|
|
|
|
user_email, invited_user_email_address
|
|
|
|
|
):
|
|
|
|
|
if user_email.lower() != invited_user_email_address.lower():
|
|
|
|
|
debug_msg("invited user email did not match expected email, abort(403)")
|
|
|
|
|
flash("You cannot accept an invite for another person.")
|
|
|
|
|
abort(403)
|
2024-05-20 12:09:49 -07:00
|
|
|
|
|
|
|
|
if not is_gov_user(user_email):
|
2024-05-13 13:39:51 -07:00
|
|
|
debug_msg("invited user has a non-government email address.")
|
|
|
|
|
flash("You must use a government email address.")
|
|
|
|
|
abort(403)
|
2024-05-10 07:51:32 -07:00
|
|
|
|
|
|
|
|
|
2024-03-19 11:32:36 -07:00
|
|
|
@main.route("/set-up-your-profile", methods=["GET", "POST"])
|
2024-03-18 13:50:23 -04:00
|
|
|
@hide_from_search_engines
|
|
|
|
|
def set_up_your_profile():
|
2024-05-06 12:15:57 -07:00
|
|
|
|
2024-05-09 14:04:30 -07:00
|
|
|
debug_msg(f"Enter set_up_your_profile with request.args {request.args}")
|
|
|
|
|
code = request.args.get("code")
|
|
|
|
|
state = request.args.get("state")
|
2024-10-25 16:55:34 -04:00
|
|
|
|
|
|
|
|
state_key = f"login-state-{unquote(state)}"
|
2024-11-06 10:41:20 -05:00
|
|
|
stored_state = unquote(redis_client.get(state_key).decode("utf8"))
|
2024-10-25 16:55:34 -04:00
|
|
|
if state != stored_state:
|
|
|
|
|
current_app.logger.error(f"State Error: {state} != {stored_state}")
|
|
|
|
|
abort(403)
|
|
|
|
|
|
2024-05-09 14:04:30 -07:00
|
|
|
login_gov_error = request.args.get("error")
|
|
|
|
|
|
2024-11-06 14:30:28 -05:00
|
|
|
user_email = redis_client.get(f"user_email-{state}")
|
|
|
|
|
user_uuid = redis_client.get(f"user_uuid-{state}")
|
2024-11-06 10:41:20 -05:00
|
|
|
|
2024-11-06 16:04:18 -05:00
|
|
|
new_user = user_email is None or user_uuid is None
|
|
|
|
|
|
|
|
|
|
if new_user: # invite path
|
2024-10-25 16:10:45 -04:00
|
|
|
access_token = sign_in._get_access_token(code)
|
2024-10-21 16:41:33 -04:00
|
|
|
|
2024-05-09 14:04:30 -07:00
|
|
|
debug_msg("Got the access token for login.gov")
|
|
|
|
|
user_email, user_uuid = sign_in._get_user_email_and_uuid(access_token)
|
|
|
|
|
debug_msg(
|
|
|
|
|
f"Got the user_email {user_email} and user_uuid {user_uuid} from login.gov"
|
|
|
|
|
)
|
2024-11-06 14:30:28 -05:00
|
|
|
invite_data = redis_client.get(f"invitedata-{state}")
|
|
|
|
|
invite_data = json.loads(invite_data)
|
2024-05-09 14:04:30 -07:00
|
|
|
debug_msg(f"final state {invite_data}")
|
2024-11-06 16:04:18 -05:00
|
|
|
invited_user_id = invite_data["id"]
|
2024-05-09 14:04:30 -07:00
|
|
|
invited_user_email_address = get_invited_user_email_address(invited_user_id)
|
|
|
|
|
debug_msg(f"email address from the invite_date is {invited_user_email_address}")
|
2024-05-10 07:51:32 -07:00
|
|
|
check_invited_user_email_address_matches_expected(
|
|
|
|
|
user_email, invited_user_email_address
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
invited_user_accept_invite(invited_user_id)
|
|
|
|
|
debug_msg(
|
2024-11-06 16:04:18 -05:00
|
|
|
f"accepted invite user {invited_user_email_address} to service {invite_data['service']}"
|
2024-05-10 07:51:32 -07:00
|
|
|
)
|
2024-05-09 14:04:30 -07:00
|
|
|
# We need to avoid taking a second trip through the login.gov code because we cannot pull the
|
|
|
|
|
# access token twice. So once we retrieve these values, let's park them in redis for 15 minutes
|
2024-05-10 07:51:32 -07:00
|
|
|
put_invite_data_in_redis(
|
|
|
|
|
state, invite_data, user_email, user_uuid, invited_user_email_address
|
2024-05-09 14:04:30 -07:00
|
|
|
)
|
2024-05-06 12:15:57 -07:00
|
|
|
|
2024-05-09 14:04:30 -07:00
|
|
|
form = SetupUserProfileForm()
|
2024-05-06 12:15:57 -07:00
|
|
|
|
2024-11-06 16:04:18 -05:00
|
|
|
if form.validate_on_submit() and not new_user:
|
2024-05-10 07:51:32 -07:00
|
|
|
invite_data, user_email, user_uuid, invited_user_email_address = (
|
|
|
|
|
get_invite_data_from_redis(state)
|
|
|
|
|
)
|
2024-05-07 13:58:59 -07:00
|
|
|
|
2024-05-10 07:51:32 -07:00
|
|
|
# create or update the user
|
2024-05-06 13:12:27 -07:00
|
|
|
user = user_api_client.get_user_by_uuid_or_email(user_uuid, user_email)
|
|
|
|
|
if user is None:
|
|
|
|
|
user = User.register(
|
|
|
|
|
name=form.name.data,
|
|
|
|
|
email_address=user_email,
|
|
|
|
|
mobile_number=form.mobile_number.data,
|
|
|
|
|
password=str(uuid.uuid4()),
|
|
|
|
|
auth_type="sms_auth",
|
|
|
|
|
)
|
2024-05-07 13:58:59 -07:00
|
|
|
debug_msg(f"registered user {form.name.data} with email {user_email}")
|
2024-05-09 13:08:34 -07:00
|
|
|
else:
|
2024-05-09 14:04:30 -07:00
|
|
|
user.update(mobile_number=form.mobile_number.data, name=form.name.data)
|
2024-05-09 13:08:34 -07:00
|
|
|
debug_msg(f"updated user {form.name.data}")
|
|
|
|
|
|
2024-05-06 13:12:27 -07:00
|
|
|
# activate the user
|
|
|
|
|
user = user_api_client.get_user_by_uuid_or_email(user_uuid, user_email)
|
|
|
|
|
activate_user(user["id"])
|
2024-05-07 13:58:59 -07:00
|
|
|
debug_msg("activated user")
|
2024-05-06 13:12:27 -07:00
|
|
|
usr = User.from_id(user["id"])
|
|
|
|
|
usr.add_to_service(
|
2024-11-06 16:04:18 -05:00
|
|
|
invite_data["service"],
|
2024-05-06 13:12:27 -07:00
|
|
|
invite_data["permissions"],
|
|
|
|
|
invite_data["folder_permissions"],
|
2024-11-06 16:04:18 -05:00
|
|
|
invite_data["from_user"],
|
2024-05-06 13:12:27 -07:00
|
|
|
)
|
2024-11-06 16:04:18 -05:00
|
|
|
debug_msg(f"Added user {usr.email_address} to service {invite_data['service']}")
|
2024-07-25 09:10:25 -07:00
|
|
|
# notify-admin-1766
|
|
|
|
|
# redirect new users to templates area of new service instead of dashboard
|
2024-11-06 16:04:18 -05:00
|
|
|
service_id = invite_data["service"]
|
2024-07-25 09:10:25 -07:00
|
|
|
url = url_for(".service_dashboard", service_id=service_id)
|
|
|
|
|
url = f"{url}/templates"
|
|
|
|
|
return redirect(url)
|
2024-05-09 14:04:30 -07:00
|
|
|
|
|
|
|
|
elif login_gov_error:
|
|
|
|
|
current_app.logger.error(f"login.gov error: {login_gov_error}")
|
|
|
|
|
abort(403)
|
|
|
|
|
|
2024-05-10 07:51:32 -07:00
|
|
|
# we take two trips through this method, but should only hit this
|
|
|
|
|
# line on the first trip. On the second trip, we should get redirected
|
|
|
|
|
# to the accounts page because we have successfully registered.
|
2024-05-09 14:04:30 -07:00
|
|
|
return render_template("views/set-up-your-profile.html", form=form)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def get_invited_user_email_address(invited_user_id):
|
|
|
|
|
# InvitedUser is an unhashable type and hard to mock in tests
|
|
|
|
|
# so this convenience method is a workaround for that
|
|
|
|
|
invited_user = InvitedUser.by_id(invited_user_id)
|
|
|
|
|
return invited_user.email_address
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def invited_user_accept_invite(invited_user_id):
|
|
|
|
|
invited_user = InvitedUser.by_id(invited_user_id)
|
2024-05-31 17:20:08 -04:00
|
|
|
|
2024-05-16 09:11:11 -07:00
|
|
|
if invited_user.status == "expired":
|
|
|
|
|
current_app.logger.error("User invitation has expired")
|
2024-05-31 17:20:08 -04:00
|
|
|
flash(
|
|
|
|
|
"Your invitation has expired; please contact the person who invited you for additional help."
|
|
|
|
|
)
|
|
|
|
|
abort(401)
|
|
|
|
|
|
|
|
|
|
if invited_user.status == "cancelled":
|
|
|
|
|
current_app.logger.error("User invitation has been cancelled")
|
|
|
|
|
flash(
|
|
|
|
|
"Your invitation is no longer valid; please contact the person who invited you for additional help."
|
|
|
|
|
)
|
2024-05-16 09:11:11 -07:00
|
|
|
abort(401)
|
2024-05-31 17:20:08 -04:00
|
|
|
|
2024-05-09 14:04:30 -07:00
|
|
|
invited_user.accept_invite()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def debug_msg(msg):
|
|
|
|
|
current_app.logger.debug(hilite(msg))
|