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
5cbf57e1fb38f2736b2d979b7341cdf93f131e83
notifications-admin/app/templates/views/signin.html

43 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" %}
Add a WTForms-compatible textbox macro This macro: - accepts a WTForm form field as a parameter - renders a form field which follows the GOV.UK Elements patterns, both visually and in markup terms It then changes any page which uses either: - the old, non-WTForms macro or - the old, WTFforms `render_field` macro …to use this new macro and removes both of the old ones. It also adds the option to display hint text above the textbox.
2016-01-11 13:15:10 +00:00
{% from "components/textbox.html" import textbox %}
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 %}
Sign in
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
Replace `grid-row` with `govuk-grid-row` Replaced all instances of `grid-row` in the HTML and JavaScript with `govuk-grid-row`, which is the new GOV.UK Frontend class.
2020-02-19 11:57:15 +00:00
<div class="govuk-grid-row">
Replace `column-two-thirds` with `govuk-grid-column-two-thirds`
2020-02-19 12:36:02 +00:00
<div class="govuk-grid-column-two-thirds">
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 %}
<h1 class="heading-large">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 %}
Don’t allow paragraphs without class attribute All paragraphs should have class="govuk-body", or be otherwise custom-styled. This commit adds some extra checks to our test fixture that looks for paragraphs that don’t have any styling. Our test coverage is pretty good, so this should check almost all pages, and prevent regressions. I’ve done this in such a way that it can be extended for other elements (e.g. links) in the future.
2020-05-29 17:11:01 +01:00
<p class="govuk-body">
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 %}
Don’t allow paragraphs without class attribute All paragraphs should have class="govuk-body", or be otherwise custom-styled. This commit adds some extra checks to our test fixture that looks for paragraphs that don’t have any styling. Our test coverage is pretty good, so this should check almost all pages, and prevent regressions. I’ve done this in such a way that it can be extended for other elements (e.g. links) in the future.
2020-05-29 17:11:01 +01:00
<p class="govuk-body">
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 %}
<h1 class="heading-large">Sign in</h1>
Don’t allow paragraphs without class attribute All paragraphs should have class="govuk-body", or be otherwise custom-styled. This commit adds some extra checks to our test fixture that looks for paragraphs that don’t have any styling. Our test coverage is pretty good, so this should check almost all pages, and prevent regressions. I’ve done this in such a way that it can be extended for other elements (e.g. links) in the future.
2020-05-29 17:11:01 +01:00
<p class="govuk-body">
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 you do not have an account, you can
Update all links to use GOVUK Frontend style Includes: - turning off :visited styles to match existing design - swapping heading classes used to make links bold for the GOVUK Frontend bold override class - adding visually hidden text to some links to make them work when isolated from their context We may need to revisit whether some links, such as those for documentation and features, may benefit from having some indication that their target has been visited.
2019-12-06 07:53:46 +00:00
<a class="govuk-link govuk-link--no-visited-state" href="{{ url_for('.register') }}">create one now</a>.
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
</p>
{% 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) %}
Add autocomplete to email address on register form GOV.UK Design System recommends: > You should also set the autocomplete attribute to email. This lets > browsers autofill the email address on a user’s behalf if they’ve > entered it previously. Only doing this on the register and sign in forms because it’s unlikely to be helpful where a user is trying to enter someone else’s email address.
2019-07-16 09:01:21 +01:00
{{ textbox(form.email_address, autocomplete='email') }}
Add autocomplete attribute to password fields This helps the browser autocomplete them with the right thing. Value based on https://www.w3.org/TR/WCAG21/#input-purposes
2019-07-16 17:01:54 +01:00
{{ textbox(form.password, autocomplete='current-password') }}
Change 'forgot' to 'forgotten'
2020-02-24 11:57:48 +00:00
{{ page_footer("Continue", secondary_link=url_for('.forgot_password'), secondary_link_text="Forgotten 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