[Pmwiki-users] PmWiki password puzzle

[Ciaran]

Ah ;) makes more sense to me now, sorry!   

How about an alternative setup for the GroupAtributes page, where each
password type is a listbox, the user 'submits' a password which gets
hashed and added to the 'list' of passwords of passwords for that
particular field  ? That way they could still use spaces in their
hashes.  (Obviously a little bit of javascript would be required to
remove the passwords from the listbox, but nothing
rocket-science-esque)

- ciaran

On Thu, 26 Aug 2004 06:47:52 -0600, Patrick R. Michaud
<pmichaud at pobox.com> wrote:
> On Thu, Aug 26, 2004 at 01:39:24PM +0100, Ciaran wrote:
> > Why restrict what characters can be in the password? Does the hash
> > function not produce an 'unbroken' string anyway ?
> 
> If we want the ability to set an array of passwords in a text field, there
> has to be some character or sequence in the field that marks where
> one password begins and the next one ends; thus that character/sequence
> cannot be part of a password (unless we introduce special quoting rules,
> which seems a bit like overkill).
> 
> I.e., if, as John suggested, we want to use the GroupAttributes page
> to set four read passwords:
> 
>    read: pass1,pass2,pass3,pass4
> 
> where commas are being used to separate the passwords, then a password
> set this way cannot contain a comma.  I'm simply asking if it'd be okay
> to use space instead of comma, such that one could set
> 
>    read: pass1 pass2 pass3 pass4
> 
> This is to avoid confusion for when I introduce user-based authorization,
> where I want someone to be able to specify a list of authorized users
> separated by commas.
> 
> Of course, passwords set in configuration files via the $DefaultPasswords
> array can contain any character desired.
> 
> Pm
> 


-- 
- Ciaran
http://www.wombatinvasion.com/ (Share the love)