Project

General

Profile

Actions
Copy link

User story #3283

closed

User story #3282: Add a password input field in Directive

Add a password input field in Technique

Added by François ARMAND almost 12 years ago. Updated over 9 years ago.

Status:
Released
Priority:
1 (highest)
Assignee:
Nicolas CHARLES
Category:
Web - Config management
Target version:
2.6.0~beta1
Pull Request:
https://github.com/Normation/cf-clerk...
UX impact:
Suggestion strength:
User visibility:
Effort required:
Name check:
Fix check:
Regression:

Description

CF-Clerk should understand a new type of input field for passwords.

Actions
Copy link
 #1

Updated by François ARMAND almost 12 years ago

  • Tracker changed from 6 to Enhancement

Example of existing password definition:

<INPUT>
        <NAME>OVPN_CLIENT_REMOTE_PASSWORD</NAME>
        <DESCRIPTION>Remote password</DESCRIPTION>
        <CONSTRAINT>
          <MAYBEEMPTY>true</MAYBEEMPTY>
        </CONSTRAINT>
      </INPUT>
<INPUT>
        <NAME>USERGROUP_USER_PASSWORD</NAME>
        <DESCRIPTION>Password for this account</DESCRIPTION>
        <CONSTRAINT>
          <MAYBEEMPTY>true</MAYBEEMPTY>
        </CONSTRAINT>
      </INPUT>

Both have a "may be empty = true" constrain, so it seems important that password should be blankable.

Actions
Copy link
 #2

Updated by François ARMAND almost 12 years ago

A PASSWORD specification in a Technique is alike an INPUT one, but it (optionnaly) takes a new parameter, HASH, specifying a hash algorithm to use. If none is specified (or "USER" is), then the hash algo is chosen when filling the directive.
Ex:
<PASSWORD>
<NAME>USERGROUP_USER_PASSWORD</NAME>
<DESCRIPTION>Password for this account</DESCRIPTION>
<CONSTRAINT>
<MAYBEEMPTY>true</MAYBEEMPTY>
</CONSTRAINT>
<HASH>SHA256</HASH>
</PASSWORD>

An alternative could be to be able to choose among a list of HASH, and having the list of all HASH available if none specified. Something like: <HASH>md5,sha1</HASH> will let the user choose among MD5 or SHA1, and <HASH /> (or no HASH tag) => full list of algo.

An alternative implementation to PASSWORD specification would have been to create a "password" type for input, and not a new field kind (it wasn't clear at the begining that it will be possible, but now it seems to be).

HASH could be in the constraint tag (it seems more natural with a PASSWORD tag to have HASH directly as a children, but for INPUT CONSTRAIN -> type=password, it seems more natural to have HASH as a constraint to.

Actions
Copy link
 #3

Updated by François ARMAND almost 12 years ago

  • Status changed from 8 to 10
  • Assignee changed from François ARMAND to Jonathan CLARKE
Actions
Copy link
 #4

Updated by François ARMAND over 11 years ago

  • Status changed from 10 to Pending technical review
  • Assignee changed from Jonathan CLARKE to Nicolas CHARLES

Functional review done.

Actions
Copy link
 #5

Updated by Nicolas CHARLES over 11 years ago

  • Status changed from Pending technical review to 12

Awesome !

Actions
Copy link
 #6

Updated by Nicolas CHARLES over 11 years ago

  • Pull Request set to https://github.com/Normation/cf-clerk/pull/13
Actions
Copy link
 #7

Updated by François ARMAND over 11 years ago

  • Status changed from 12 to Pending release
  • % Done changed from 0 to 100

Applied in changeset clerk:commit:70e83644b5fb3ba4ab348ad946886cfecd93f084.

Actions
Copy link
 #8

Updated by François ARMAND over 11 years ago

Applied in changeset clerk:commit:860f0d118af42d2170c5029438090da888e2c7bd.

Actions
Copy link
 #9

Updated by Jonathan CLARKE over 11 years ago

  • Status changed from Pending release to Released

This ticket has been addressed in version 2.6.0~beta1 of Rudder, which has just been released. Please see the changelog here: https://www.rudder-project.org/foswiki/System/Documentation:ChangeLog26.

Actions
Copy link
 #10

Updated by Benoît PECCATTE over 9 years ago

  • Tracker changed from Enhancement to User story
Actions
Copy link

Also available in: Atom PDF