Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-29122

As a developer, I want to configure password policies in ezuser Field Definitions

    Details

      Description

      It should be possible to configure password policies through ezuser fields definitions.

      Constraints list:

      label input type default
      Minimum password length number 8
      Require at least one uppercase letter checkbox checked
      Require at least one lowercase letter checkbox checked
      Require at least one number checkbox checked
      Require at least one nonalphanumeric character checkbox checked

      Validation by regular expression

      As an alternative to the above, a (perl compatible) regular expression can be entered. When it is, the "simple" constraints in the previous chapter are disabled (greyed out), and not applied. The regular expression's validity must be tested when the form is submitted.

      Error text

      Independently of the chosen validation method, an input field sets the validation error message shown when the constraints aren't met.

      Validation scope

      Validation should happen in all contexts where a user password can be set:

      • User register
      • User edit
      • Change password (user profile, up v2.1)
      • REST API
      • Public API

      Backward compatibility

      Existing installations shouldn't have any of those options enabled. It can be detected in the converter / fieldtype, since the configuration for them won't exist in the database.

      New installations should have the defaults indicated above, prestored in the default user_account field definition.

        Issue Links

          Activity

          Ramzi Arfaoui created issue -
          Bertrand Dunogier made changes -
          Field Original Value New Value
          Issue Type Feature [ 2 ] Story [ 7 ]
          Workflow EZ* Feature Request Workflow [ 133321 ] EZEE and EZP Story Workflow [ 133356 ]
          Status Open [ 1 ] Backlog [ 10000 ]
          Hide
          Bertrand Dunogier added a comment -

          Moved this to a story as the feature makes a lot of sense, and was already under consideration.

          Show
          Bertrand Dunogier added a comment - Moved this to a story as the feature makes a lot of sense, and was already under consideration.
          Bertrand Dunogier made changes -
          Status Backlog [ 10000 ] Specification [ 10002 ]
          André Rømcke made changes -
          Link This issue relates to CS-6772 [ CS-6772 ]
          Jacek Foremski (Inactive) made changes -
          Fix Version/s Customer request [ 11018 ]
          Hide
          Bertrand Dunogier added a comment -

          I kind of like the idea of customizing constraints from the field definition edit form. It would need some UI specification though. For instance, can you both input a regex AND check the various "simple" options ? Shouldn't they be mutually exclusive ?

          Sylvain Guittard, what do you think ? The specification I wrote mentioned classic configuration, but this is also a valid option. One limitation would be custom validation, that doesn't really make sense together with this approach.

          Show
          Bertrand Dunogier added a comment - I kind of like the idea of customizing constraints from the field definition edit form. It would need some UI specification though. For instance, can you both input a regex AND check the various "simple" options ? Shouldn't they be mutually exclusive ? Sylvain Guittard , what do you think ? The specification I wrote mentioned classic configuration, but this is also a valid option. One limitation would be custom validation, that doesn't really make sense together with this approach.
          Hide
          Sylvain Guittard added a comment -

          Bertrand Dunogier

          For instance, can you both input a regex AND check the various "simple" options ? Shouldn't they be mutually exclusive ?

          Let's do something simple: regex OR simple options.

          Show
          Sylvain Guittard added a comment - Bertrand Dunogier For instance, can you both input a regex AND check the various "simple" options ? Shouldn't they be mutually exclusive ? Let's do something simple: regex OR simple options.
          Sylvain Guittard made changes -
          Component/s Platform UI (Admin UI & Content UI) [ 10301 ]
          Bertrand Dunogier made changes -
          Summary As a developer, I want to add password policies in ezuser FieldType As a developer, I want to configure password policies in ezuser FieldType
          Bertrand Dunogier made changes -
          Summary As a developer, I want to configure password policies in ezuser FieldType As a developer, I want to configure password policies in ezuser Field Definitions
          Bertrand Dunogier made changes -
          Description It should be possible to add password policies when adding ezuser FieldType to an existing ContentType.
          Nice to have:
          - Minimum password length (Input)
          - Require at least one uppercase letter (checkbox)
          - Require at least one lowercase letter(checkbox)
          - Require at least one number (checkbox)
          - Require at least one nonalphanumeric character (checkbox)
          - Validation Regexp (for advanced developer)(Input)
          - Error Text (Input)

          The Validation should be then available in following forms:
          - User edit
          - Change password (user profile, up v2.1)
          It should be possible to configure password policies through {{ezuser}} fields definitions.

          h3. Constraints list:
          ||label||input type||default||
          |Minimum password length|number|8|
          |Require at least one uppercase letter|checkbox|checked|
          |Require at least one lowercase letter|checkbox|checked|
          |Require at least one number|checkbox|checked|
          |Require at least one nonalphanumeric character|checkbox|checked|

          h3. Validation by regular expression
          As an alternative to the above, a regular expression can be entered. When one is, the "simple" constraints in the previous chapter are disabled (greyed out), and not applied. The regular expression's validity must be tested when the form is submitted.

          h3. Error text
          Independently of the chosen validation method, an input field sets the validation error message shown when the constraints aren't met.

          h3. Validation scope
          Validation should happen in all contexts where a user password can be set:
          - User edit
          - Change password (user profile, up v2.1)
          - REST API
          - Public API
          Bertrand Dunogier made changes -
          Description It should be possible to configure password policies through {{ezuser}} fields definitions.

          h3. Constraints list:
          ||label||input type||default||
          |Minimum password length|number|8|
          |Require at least one uppercase letter|checkbox|checked|
          |Require at least one lowercase letter|checkbox|checked|
          |Require at least one number|checkbox|checked|
          |Require at least one nonalphanumeric character|checkbox|checked|

          h3. Validation by regular expression
          As an alternative to the above, a regular expression can be entered. When one is, the "simple" constraints in the previous chapter are disabled (greyed out), and not applied. The regular expression's validity must be tested when the form is submitted.

          h3. Error text
          Independently of the chosen validation method, an input field sets the validation error message shown when the constraints aren't met.

          h3. Validation scope
          Validation should happen in all contexts where a user password can be set:
          - User edit
          - Change password (user profile, up v2.1)
          - REST API
          - Public API
          It should be possible to configure password policies through {{ezuser}} fields definitions.

          h3. Constraints list:
          ||label||input type||default||
          |Minimum password length|number|8|
          |Require at least one uppercase letter|checkbox|checked|
          |Require at least one lowercase letter|checkbox|checked|
          |Require at least one number|checkbox|checked|
          |Require at least one nonalphanumeric character|checkbox|checked|

          h3. Validation by regular expression
          As an alternative to the above, a regular expression can be entered. When one is, the "simple" constraints in the previous chapter are disabled (greyed out), and not applied. The regular expression's validity must be tested when the form is submitted.

          h3. Error text
          Independently of the chosen validation method, an input field sets the validation error message shown when the constraints aren't met.

          h3. Validation scope
          Validation should happen in all contexts where a user password can be set:
          - User edit
          - Change password (user profile, up v2.1)
          - REST API
          - Public API

          h3. Backward compatibility
          Existing installations shouldn't have any of those options enabled. It can be detected in the converter / fieldtype, since the configuration for them won't exist in the database.

          New installations should have the defaults indicated above, prestored in the default {{user_account}} field definition.
          Bertrand Dunogier made changes -
          Description It should be possible to configure password policies through {{ezuser}} fields definitions.

          h3. Constraints list:
          ||label||input type||default||
          |Minimum password length|number|8|
          |Require at least one uppercase letter|checkbox|checked|
          |Require at least one lowercase letter|checkbox|checked|
          |Require at least one number|checkbox|checked|
          |Require at least one nonalphanumeric character|checkbox|checked|

          h3. Validation by regular expression
          As an alternative to the above, a regular expression can be entered. When one is, the "simple" constraints in the previous chapter are disabled (greyed out), and not applied. The regular expression's validity must be tested when the form is submitted.

          h3. Error text
          Independently of the chosen validation method, an input field sets the validation error message shown when the constraints aren't met.

          h3. Validation scope
          Validation should happen in all contexts where a user password can be set:
          - User edit
          - Change password (user profile, up v2.1)
          - REST API
          - Public API

          h3. Backward compatibility
          Existing installations shouldn't have any of those options enabled. It can be detected in the converter / fieldtype, since the configuration for them won't exist in the database.

          New installations should have the defaults indicated above, prestored in the default {{user_account}} field definition.
          It should be possible to configure password policies through {{ezuser}} fields definitions.

          h3. Constraints list:
          ||label||input type||default||
          |Minimum password length|number|8|
          |Require at least one uppercase letter|checkbox|checked|
          |Require at least one lowercase letter|checkbox|checked|
          |Require at least one number|checkbox|checked|
          |Require at least one nonalphanumeric character|checkbox|checked|

          h3. Validation by regular expression
          As an alternative to the above, a regular expression can be entered. When one is, the "simple" constraints in the previous chapter are disabled (greyed out), and not applied. The regular expression's validity must be tested when the form is submitted.

          h3. Error text
          Independently of the chosen validation method, an input field sets the validation error message shown when the constraints aren't met.

          h3. Validation scope
          Validation should happen in all contexts where a user password can be set:
          - User register
          - User edit
          - Change password (user profile, up v2.1)
          - REST API
          - Public API

          h3. Backward compatibility
          Existing installations shouldn't have any of those options enabled. It can be detected in the converter / fieldtype, since the configuration for them won't exist in the database.

          New installations should have the defaults indicated above, prestored in the default {{user_account}} field definition.
          Bertrand Dunogier made changes -
          Description It should be possible to configure password policies through {{ezuser}} fields definitions.

          h3. Constraints list:
          ||label||input type||default||
          |Minimum password length|number|8|
          |Require at least one uppercase letter|checkbox|checked|
          |Require at least one lowercase letter|checkbox|checked|
          |Require at least one number|checkbox|checked|
          |Require at least one nonalphanumeric character|checkbox|checked|

          h3. Validation by regular expression
          As an alternative to the above, a regular expression can be entered. When one is, the "simple" constraints in the previous chapter are disabled (greyed out), and not applied. The regular expression's validity must be tested when the form is submitted.

          h3. Error text
          Independently of the chosen validation method, an input field sets the validation error message shown when the constraints aren't met.

          h3. Validation scope
          Validation should happen in all contexts where a user password can be set:
          - User register
          - User edit
          - Change password (user profile, up v2.1)
          - REST API
          - Public API

          h3. Backward compatibility
          Existing installations shouldn't have any of those options enabled. It can be detected in the converter / fieldtype, since the configuration for them won't exist in the database.

          New installations should have the defaults indicated above, prestored in the default {{user_account}} field definition.
          It should be possible to configure password policies through {{ezuser}} fields definitions.

          h3. Constraints list:
          ||label||input type||default||
          |Minimum password length|number|8|
          |Require at least one uppercase letter|checkbox|checked|
          |Require at least one lowercase letter|checkbox|checked|
          |Require at least one number|checkbox|checked|
          |Require at least one nonalphanumeric character|checkbox|checked|

          h3. Validation by regular expression
          As an alternative to the above, a (perl compatible) regular expression can be entered. When it is, the "simple" constraints in the previous chapter are disabled (greyed out), and not applied. The regular expression's validity must be tested when the form is submitted.

          h3. Error text
          Independently of the chosen validation method, an input field sets the validation error message shown when the constraints aren't met.

          h3. Validation scope
          Validation should happen in all contexts where a user password can be set:
          - User register
          - User edit
          - Change password (user profile, up v2.1)
          - REST API
          - Public API

          h3. Backward compatibility
          Existing installations shouldn't have any of those options enabled. It can be detected in the converter / fieldtype, since the configuration for them won't exist in the database.

          New installations should have the defaults indicated above, prestored in the default {{user_account}} field definition.
          Bertrand Dunogier made changes -
          Status Specification [ 10002 ] Specification Review [ 10038 ]
          Sylvain Guittard made changes -
          Remote Link This issue links to "Feature (Web Link)" [ 18622 ]
          Barbara Grajczyk made changes -
          Assignee Bertrand Dunogier [ bertrand.dunogier@ez.no ] Barbara Grajczyk [ barbara.grajczyk@ez.no ]
          Barbara Grajczyk made changes -
          Status Specification Review [ 10038 ] Specification Done [ 10003 ]
          Barbara Grajczyk made changes -
          Status Specification Done [ 10003 ] Development [ 3 ]
          Show
          Barbara Grajczyk added a comment - PR merged: https://github.com/ezsystems/ezpublish-kernel/commit/ca35b890be6dc61e242a180d2fc9d33b9a8bfa1e https://github.com/ezsystems/repository-forms/commit/23af1373498403d877ea553ef3ef78e0e19fbb32 https://github.com/ezsystems/ezplatform-admin-ui/commit/d4d50d3c30bcc8a06c491ed6d92ae625a5e646b2
          Barbara Grajczyk made changes -
          Status Development [ 3 ] Development Done [ 5 ]
          Barbara Grajczyk made changes -
          Status Development Done [ 5 ] QA [ 10008 ]
          Barbara Grajczyk made changes -
          Status QA [ 10008 ] QA Done [ 10007 ]
          Fix Version/s 2.4.0-rc1 [ 15090 ]
          Assignee Barbara Grajczyk [ barbara.grajczyk@ez.no ]
          Hide
          Barbara Grajczyk added a comment -

          QA approved.

          Show
          Barbara Grajczyk added a comment - QA approved.
          Barbara Grajczyk made changes -
          Status QA Done [ 10007 ] Closed [ 6 ]
          Resolution Done [ 9 ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Backlog Backlog
          3d 6h 30m 1 Bertrand Dunogier 23/Apr/18 4:35 PM
          Backlog Backlog Specification Specification
          33s 1 Bertrand Dunogier 23/Apr/18 4:36 PM
          Specification Specification Specification Review Specification Review
          38d 14m 1 Bertrand Dunogier 31/May/18 4:51 PM
          Specification Review Specification Review Specification Done Specification Done
          195d 22h 12m 1 Barbara Grajczyk 13/Dec/18 2:04 PM
          Specification Done Specification Done Development Development
          4s 1 Barbara Grajczyk 13/Dec/18 2:04 PM
          Development Development Development Done Development Done
          40s 1 Barbara Grajczyk 13/Dec/18 2:04 PM
          Development Done Development Done QA QA
          1m 32s 1 Barbara Grajczyk 13/Dec/18 2:06 PM
          QA QA QA Done QA Done
          22s 1 Barbara Grajczyk 13/Dec/18 2:06 PM
          QA Done QA Done Closed Closed
          16s 1 Barbara Grajczyk 13/Dec/18 2:06 PM

            People

            • Assignee:
              Unassigned
              Reporter:
              Ramzi Arfaoui
            • Votes:
              1 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: