darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-09-08 08:28:15 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
f7f1b7fb3ee2807bc2be86be5d51f019409b38f8
notifications-admin/app/templates/views/signin.html

48 lines
1.4 KiB
HTML
Raw Normal View History

Make spacing and position of banners consistent Banners should always be the first thing on the page. Because headers already have padding we don’t want to put padding on the container. So banners should also have top padding to distance then from the red bar. They should also sit in the 3/4 column if the page has side navigation. This commit adds a new template (`withoutnav_template.html`) which extends `admin_template.html`. All views then extend one or the other, never the `admin_template.html` directly. This means that `admin_template.html` doesn’t have to make decisions about where the flash messages are displayed.
2016-02-01 12:15:38 +00:00
{% extends "withoutnav_template.html" %}
Rename `submit_form` component to `page_footer` Submit form was - a confusing name in itself - not descriptive, because it also has an optional ‘back’ link This commit also puts this component in as many pages as possible, stripping out any hard-coded buttons and links. It replaces any usage of buttons for ‘back’, because these are links, not buttons (ie they don’t change any data).
2016-01-07 20:11:22 +00:00
{% from "components/page-footer.html" import page_footer %}
Use a macro for form tags This will stop us repeatedly forgetting to add `novalidate` and `autocomplete='off'` to our forms (which is how most of them are set up). It uses sensible defaults, based on how we most-commonly configure forms: - most of our forms are `post`ed (but this can be overridden) - `autocomplete` should only be enabled where it makes sense, otherwise it’s more annoying than useful (but this can be overriden) - we should never be using HTML5 form validation because our own error styles and messages are better
2018-09-19 12:39:36 +01:00
{% from "components/form.html" import form_wrapper %}
Create base forms for registration and sign in Created routes and forms for registration, sign in, and registration from an invite. Also tidied up assets folder, removed copy of fronted toolkit.
2015-11-25 16:21:28 +00:00
Include service name in page `<title>` In pages specific to a service (e.g. dashboard and sub pages) the title needs to distinguish which service it applies to. This is mainly to give context to screen reader users who could be managing multiple services. Implementing this uses template inheritance: `page_title` includes `per_page_title` includes `service_page_title` ‘GOV.UK Notify’ is inserted into every page title. Pages that set `service_page_title` get the service name inserted too.
2017-02-13 10:45:15 +00:00
{% block per_page_title %}
Stop using `logged_in_client` fixture We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `logged_in_client`. This is not as good because: - it returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests using `logged_in_client` to: use `client_request` instead.
2021-12-31 12:08:14 +00:00
{% if again %}
You need to sign in again
{% else %}
Sign in
{% endif %}
Create base forms for registration and sign in Created routes and forms for registration, sign in, and registration from an invite. Also tidied up assets folder, removed copy of fronted toolkit.
2015-11-25 16:21:28 +00:00
{% endblock %}
Make spacing and position of banners consistent Banners should always be the first thing on the page. Because headers already have padding we don’t want to put padding on the container. So banners should also have top padding to distance then from the red bar. They should also sit in the 3/4 column if the page has side navigation. This commit adds a new template (`withoutnav_template.html`) which extends `admin_template.html`. All views then extend one or the other, never the `admin_template.html` directly. This means that `admin_template.html` doesn’t have to make decisions about where the flash messages are displayed.
2016-02-01 12:15:38 +00:00
{% block maincolumn_content %}
Create base forms for registration and sign in Created routes and forms for registration, sign in, and registration from an invite. Also tidied up assets folder, removed copy of fronted toolkit.
2015-11-25 16:21:28 +00:00
Update dashboard and template flow (#514) * Updated header and footer * Moved files around and updated gulpfile to correct the build process when it goes to production * Updated fonts * Adjusted grid templating * Adding images to assets * Updated account pages, dashboard, and pages in message sending flow * Updated the styling for the landing pages in the account section once logged in
2023-06-08 13:12:00 -04:00
<div class="grid-row">
<div class="tablet:grid-col-12">
Create base forms for registration and sign in Created routes and forms for registration, sign in, and registration from an invite. Also tidied up assets folder, removed copy of fronted toolkit.
2015-11-25 16:21:28 +00:00
Show a more useful message if you get signed out > Users that allow their session to expire, or access a bookmarked link > are told they need to "Sign in to access this page" - we should > explain that it's because they've been away a while, so that they > understand why they're being asked to log in again. – https://www.pivotaltracker.com/story/show/140016919 The message we were showing before (Please log in to access this page is the default message from Flask Login). In order to stop this flash message from appearing, we need to override the default handler for when a user is unauthorised. We’re overriding it with the same behaviour, minus the flash message. If you navigate deliberately to the sign in page it’s unchanged. Content is Sheryll-approved.
2017-02-16 13:33:32 +00:00
{% if again %}
Updating site to use USWDS styles (#509) * Updated header and footer * Updated fonts * Moved files around and updated gulpfile to correct the build process when it goes to production * Adjusted grid templating * Added images to assets * Update app/templates/components/uk_components/footer/template.njk Co-authored-by: Steven Reilly <stvnrlly@users.noreply.github.com>
2023-06-06 15:28:24 -04:00
<h1 class="font-body-2xl margin-bottom-3">You need to sign in again</h1>
check users' session id. when a user enters their 2FA code, the API will store a random UUID against them in the database - this code is then stored on the cookie on the front end. At the beginning of each authenticated request, we do the following steps: * Retrieve the user's cookie, and get the user_id from it * Request that user's details from the database * populate current_user with the DB model * run the login_required decorator, which calls current_user.is_authenticated is_authenticated now also checks that the database model matches the cookie for session_id. The potential states and meanings are as follows: database | cookie | meaning ----------+--------+--------- None | None | New user, or system just been deployed. | | Redirect to start page. ----------+--------+--------- 'abc' | None | New browser (or cleared cookies). Redirect to | | start page. ----------+--------+--------- None | 'abc' | Invalid state (cookie is set from user obj, so | | would only happen if DB is cleared) ----------+--------+--------- 'abc' | 'abc' | Same browser. Business as usual ----------+--------+--------- 'abc' | 'def' | Different browser in cookie - db has been changed | | since then. Redirect to start
2017-02-17 14:06:09 +00:00
{% if other_device %}
Updating site to use USWDS styles (#509) * Updated header and footer * Updated fonts * Moved files around and updated gulpfile to correct the build process when it goes to production * Adjusted grid templating * Added images to assets * Update app/templates/components/uk_components/footer/template.njk Co-authored-by: Steven Reilly <stvnrlly@users.noreply.github.com>
2023-06-06 15:28:24 -04:00
<p>
check users' session id. when a user enters their 2FA code, the API will store a random UUID against them in the database - this code is then stored on the cookie on the front end. At the beginning of each authenticated request, we do the following steps: * Retrieve the user's cookie, and get the user_id from it * Request that user's details from the database * populate current_user with the DB model * run the login_required decorator, which calls current_user.is_authenticated is_authenticated now also checks that the database model matches the cookie for session_id. The potential states and meanings are as follows: database | cookie | meaning ----------+--------+--------- None | None | New user, or system just been deployed. | | Redirect to start page. ----------+--------+--------- 'abc' | None | New browser (or cleared cookies). Redirect to | | start page. ----------+--------+--------- None | 'abc' | Invalid state (cookie is set from user obj, so | | would only happen if DB is cleared) ----------+--------+--------- 'abc' | 'abc' | Same browser. Business as usual ----------+--------+--------- 'abc' | 'def' | Different browser in cookie - db has been changed | | since then. Redirect to start
2017-02-17 14:06:09 +00:00
We signed you out because you logged in to Notify on another device.
</p>
{% else %}
Updating site to use USWDS styles (#509) * Updated header and footer * Updated fonts * Moved files around and updated gulpfile to correct the build process when it goes to production * Adjusted grid templating * Added images to assets * Update app/templates/components/uk_components/footer/template.njk Co-authored-by: Steven Reilly <stvnrlly@users.noreply.github.com>
2023-06-06 15:28:24 -04:00
<p>
Replace haven't with have not
2019-09-13 12:53:22 +01:00
We signed you out because you have not used Notify for a while.
check users' session id. when a user enters their 2FA code, the API will store a random UUID against them in the database - this code is then stored on the cookie on the front end. At the beginning of each authenticated request, we do the following steps: * Retrieve the user's cookie, and get the user_id from it * Request that user's details from the database * populate current_user with the DB model * run the login_required decorator, which calls current_user.is_authenticated is_authenticated now also checks that the database model matches the cookie for session_id. The potential states and meanings are as follows: database | cookie | meaning ----------+--------+--------- None | None | New user, or system just been deployed. | | Redirect to start page. ----------+--------+--------- 'abc' | None | New browser (or cleared cookies). Redirect to | | start page. ----------+--------+--------- None | 'abc' | Invalid state (cookie is set from user obj, so | | would only happen if DB is cleared) ----------+--------+--------- 'abc' | 'abc' | Same browser. Business as usual ----------+--------+--------- 'abc' | 'def' | Different browser in cookie - db has been changed | | since then. Redirect to start
2017-02-17 14:06:09 +00:00
</p>
{% endif %}
Show a more useful message if you get signed out > Users that allow their session to expire, or access a bookmarked link > are told they need to "Sign in to access this page" - we should > explain that it's because they've been away a while, so that they > understand why they're being asked to log in again. – https://www.pivotaltracker.com/story/show/140016919 The message we were showing before (Please log in to access this page is the default message from Flask Login). In order to stop this flash message from appearing, we need to override the default handler for when a user is unauthorised. We’re overriding it with the same behaviour, minus the flash message. If you navigate deliberately to the sign in page it’s unchanged. Content is Sheryll-approved.
2017-02-16 13:33:32 +00:00
{% else %}
Updating site to use USWDS styles (#509) * Updated header and footer * Updated fonts * Moved files around and updated gulpfile to correct the build process when it goes to production * Adjusted grid templating * Added images to assets * Update app/templates/components/uk_components/footer/template.njk Co-authored-by: Steven Reilly <stvnrlly@users.noreply.github.com>
2023-06-06 15:28:24 -04:00
<h1 class="font-body-2xl margin-bottom-3">Sign in</h1>
code review feedback
2023-12-14 07:34:33 -08:00
{% if login_gov_enabled %}
initial for login.gov integration
2023-10-18 15:18:37 -07:00
<p>
notify-admin-338 login.gov integration
2023-11-02 14:10:22 -07:00
Test login.gov authentication:
fix initial url import to signin.html
2023-12-14 09:17:32 -08:00
<a class="usa-link" href="{{ initial_signin_url }}">Login.gov</a>.
initial for login.gov integration
2023-10-18 15:18:37 -07:00
</p>
notify-admin-338 login.gov integration
2023-11-02 14:10:22 -07:00
{% endif %}
Show a more useful message if you get signed out > Users that allow their session to expire, or access a bookmarked link > are told they need to "Sign in to access this page" - we should > explain that it's because they've been away a while, so that they > understand why they're being asked to log in again. – https://www.pivotaltracker.com/story/show/140016919 The message we were showing before (Please log in to access this page is the default message from Flask Login). In order to stop this flash message from appearing, we need to override the default handler for when a user is unauthorised. We’re overriding it with the same behaviour, minus the flash message. If you navigate deliberately to the sign in page it’s unchanged. Content is Sheryll-approved.
2017-02-16 13:33:32 +00:00
{% endif %}
Create base forms for registration and sign in Created routes and forms for registration, sign in, and registration from an invite. Also tidied up assets folder, removed copy of fronted toolkit.
2015-11-25 16:21:28 +00:00
Use a macro for form tags This will stop us repeatedly forgetting to add `novalidate` and `autocomplete='off'` to our forms (which is how most of them are set up). It uses sensible defaults, based on how we most-commonly configure forms: - most of our forms are `post`ed (but this can be overridden) - `autocomplete` should only be enabled where it makes sense, otherwise it’s more annoying than useful (but this can be overriden) - we should never be using HTML5 form validation because our own error styles and messages are better
2018-09-19 12:39:36 +01:00
{% call form_wrapper(autocomplete=True) %}
Convert EmailFields to GovukEmailFields Changes those fields (and sometimes also regular text input fields) in the following forms: - LoginForm - RegisterUserForm - ChangeEmailForm - FeedbackOrProblem - AcceptAgreementForm - ChangeNameForm (only name field here, but used in the same template field as ChangeEmailForm here: app/templates/views/user-profile/change.html) Also includes changes to templates that use this form and associated tests.
2020-08-07 15:16:04 +01:00
{{ form.email_address(param_extensions={"autocomplete": "email"}) }}
Convert PasswordFields to GovukPasswordFields Converts them directly in the following forms: - LoginForm - ConfirmPasswordForm Changes the password function to return GovukPasswordField instead of PasswordField which effects the following forms: - RegisterUserForm - RegisterUserFromInviteForm - RegisterUserFromOrgInviteForm - NewPasswordForm - ChangePasswordForm It also updates StringField on RegisterUserFromOrgInviteForm to GovukTextInputField Also includes changes to templates that use this form and associated tests.
2020-08-07 09:53:09 +01:00
{{ form.password(param_extensions={"autocomplete": "current-password"}) }}
Addressing most of the low-lift items from the Notify content audit (#491)
2023-05-08 10:49:30 -04:00
{{ page_footer("Continue", secondary_link=password_reset_url, secondary_link_text="Forgot your password?") }}
Use a macro for form tags This will stop us repeatedly forgetting to add `novalidate` and `autocomplete='off'` to our forms (which is how most of them are set up). It uses sensible defaults, based on how we most-commonly configure forms: - most of our forms are `post`ed (but this can be overridden) - `autocomplete` should only be enabled where it makes sense, otherwise it’s more annoying than useful (but this can be overriden) - we should never be using HTML5 form validation because our own error styles and messages are better
2018-09-19 12:39:36 +01:00
{% endcall %}
Replace tabs with two spaces for consistency
2016-02-01 16:57:29 +00:00
</div>
Create base forms for registration and sign in Created routes and forms for registration, sign in, and registration from an invite. Also tidied up assets folder, removed copy of fronted toolkit.
2015-11-25 16:21:28 +00:00
</div>
Amend text
2015-12-04 14:50:23 +00:00
{% endblock %}
Reference in New Issue Copy Permalink