On 23/02/2009, at 4:45 PM, Oleg Gusakov wrote:
Brett Porter wrote:
I don't view this as a temporary measure - as my second comment
said, you may need a password to get the plugin in the first place.
How would you address this case?
I have never seen an environment where read-only access to central
or central replica is authenticated. Short of that it's just another
plugin to be downloaded and used. Or I completely missed the question?
That's right, it's the situation I was thinking of. I was thinking
along the lines of a vetted repository where direct use of central is
not used. It's maybe still unlikely that would be authenticated, but I
wouldn't rule it out.
Thinking it through, to me this actually feels a more natural fit in
the CLI now, along with the other settings-based operations, pretty
much symmetrical with the location of the operation to decode the
passwords in the settings file. For a user, manipulation of the
settings file is generally a set-up task, before you do anything else.
This location also makes it very snappy, not going through the whole
plugin cycle, and had very little impact on the code since it was
already mostly achieved through the sec-dispatcher and cipher. A
plugin for this would see infrequent releases - perhaps none - which
seems an odd evolutionary cycle for an independent piece of code.
Not that tied to it being in the CLI if a suitable replacement is
already in place, but I hope this is somewhat convincing :)
Cheers,
Brett
--
Brett Porter
[email protected]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
