Umm, well, again, Cherokee-admin can be ran with the default generated password behavior or one can use the -u to make it passwordless. There isn't any safeguard to ask the user if they are sure of what they are doing with a -u ran admin. :) That's the big potential opening especially where people become more frustrated with Cherokee's good intentioned, but hard on the admin random password.
Affording manual password setting isn't unusual, it's how everything else works :) I am all for a PGP or other crypto key based mechanism though. +1 Unsure of the complexity for users and to implement. Doubt it's a lunch hour project. I have a dozen machines running Cherokee actively. So the admin stop/start/password copy and paste dance has me worn out :) I am about to run the admin passwordless and put other protections in place --- like a user and password security pop up standard validation with whatever I have hard set. Yeah, reverse proxy will suffice :) Actually off now to test this way of hard setting password and leaving the admin running permanent passwordless. On 1/24/12, M. David Peterson <[email protected]> wrote: > On Mon, Jan 23, 2012 at 3:04 PM, pub crawler > <[email protected]>wrote: > >> I support the ideas of both the cancel/undo. >> > > Better still would be using a git-based versioning system that generates a > commit with every save, exposing the ability to revert back to a previous > revision via a simple drop-down listing the sha1 of each of the previous > commits. There are a ton of additional advantages to moving towards a > git-based system (ease of deployment of configuration files to other nodes > via git push, etc.) but this particular capability would be reason enough. > > Alvaro, your thoughts? > > >> I also support the ability to set password for the cherokee-admin. >> Constant annoyance for me to kill cherokee-admin and restart it just >> to get a password to log-in.. >> > > -1: Too many people will keep cherokee-admin up and running over a > non-secure HTTP connection listening on 0.0.0.0. The last thing we need > to have happen is for someones Cherokee instance to be compromised and for > some script kiddie to be given full control over its configuration. > > I do agree that making the login process less of a burden is a beneficial > feature. Providing support for client-side PGP digital certificates* that > have been registered with a given Cherokee instance would be a MUCH more > secure and in many ways easier to manage solution. > > I'm not sure what would be required to implement support for client side > PGP certs, but at the moment the randomly generated password solution works > well enough to consider this a lower priority feature, I would think, if it > requires anything more than what can be added with minimal effort (read: > over a typical lunch break) using existing OSS libraries. > > * http://www.pgptrustcenter.com/digital-certificate-solutions > > -- > /M:D > > M. David Peterson > Co-Founder & Chief Architect, 3rd&Urban, LLC > Email: [email protected] > Voice: (801) 742-1064 > http://amp.fm | http://mdavidpeterson.com > _______________________________________________ Cherokee mailing list [email protected] http://lists.octality.com/listinfo/cherokee
