From 42b3b1f63abbaa17b4ea0780a643642f3e7ba72e Mon Sep 17 00:00:00 2001 From: smcv Date: Thu, 14 May 2015 05:49:45 -0400 Subject: [PATCH 1/5] proposal for making emailauth not force username == email address --- ...ate_authentication_from_authorization.mdwn | 92 +++++++++++++++++++ 1 file changed, 92 insertions(+) create mode 100644 doc/todo/separate_authentication_from_authorization.mdwn diff --git a/doc/todo/separate_authentication_from_authorization.mdwn b/doc/todo/separate_authentication_from_authorization.mdwn new file mode 100644 index 000000000..b4a3604ea --- /dev/null +++ b/doc/todo/separate_authentication_from_authorization.mdwn @@ -0,0 +1,92 @@ +[[plugins/openid]] and the new [[plugins/emailauth]] both assume that +the user's authentication identity (how they log in) is suitable as +an authorization identity (who they are when they have logged in). In +particular, the OpenID or email address goes into the git history. + +Relatedly, I'm not sure I'd be comfortable with enabling [[plugins/emailauth]] +on my own sites while it writes users' email addresses into the git history: +non-technical people (and many technical people for that matter) get +possessive about who can know their email address. The usual expectation for +email addresses on websites seems to be that they will be used by the site +owner (and maybe their outsourced service providers), but not available +to random third parties. The principle of least astonishment would suggest +that we should do the same here. + +(The expectation of privacy for direct git commits is rather different: +I think we can expect direct git committers to know that they +should either set a plausible non-email-address in their git identity, +like I used to use my OpenID, or have good spam filtering.) + +If we present email-based users in the "web UI" using only the local-part +of their address, we also have a potentially confusing situation where +`chris@example.com` and `chris@other.example.net` both contribute to a wiki: +if I'm reading the code right, they'd both be presented as `chris`, with no +way to change that other than using a different email address? + +Here is a sketch of a different account model that would address that: + +* An account has a username, e.g. `smcv`. It normally matches some regexp that + includes neither @ nor / (to rule out collisions with email addresses + and OpenIDs). + + * We currently allow qr{-[:alnum:]+/.:_} by default, so passwordauth + accounts can in principle collide with OpenIDs. That would probably be + worth fixing (for new account creation) anyway - I don't think we want + users with / in their names, which would make their user-page into a + subpage? + +* If passwordauth is enabled, accounts may have a password. Users can + authenticate to an account that has a password by entering that password. + The username is always the account name (because there's little reason + to do anything else). + +* If httpauth is enabled, anyone who can authenticate to the web server + automatically gets access to the account of the same name in the wiki. + (Or we could consider having a configurable map + { web-server-level username => wiki account } but the default would be + an identity mapping.) + +* If OpenID is enabled, accounts may have an OpenID. + The owner of that OpenID can log in, and gets logged-in to that account. + Either reusing the same OpenID for multiple accounts is not allowed, or + if the same OpenID is attached to more than one account the user can choose + (as an extra step). Optionally, more than one OpenID could be allowed. + +* If emailauth is enabled, accounts may have an email address. + Users can authenticate to an account that has an email + address (and is not a grandfathered OpenID) by using the token challenge. + (passwordauth accounts could already do a password-reset, so this is not + any less secure.) + +* Creating an account from an email address (maybe also OpenID?) has a new + step: choosing a username, with some text about "this name will appear + in recentchanges and in the wiki's history". The default would be the + local-part (user) from the email address. + +* Grandfathered OpenID support: every existing account that looks like an + OpenID has that OpenID associated with it, and it cannot be changed or + removed. The displayed form is openiduser(). + +* Grandfathered emailauth support, if required (but it might not be required + if we implement this model before the next ikiwiki release): every existing + account that looks like an email address has that email address associated + with it, and it cannot be changed or removed. The displayed form is + emailuser() but we should maybe change that to output something more + like `smcv@…`. + +* Hypothetically, an account could also have a https client certificate + for a new client-certificate plugin, or a Google account for a new OAuth2 + plugin, or whatever, and all of the above applies equally. + +* Unlike the current OpenID support, if the user's authentication provider + goes away (or if Google stops doing OAuth2 and moves on to the next big + thing), they can associate a different authentication identity with + their existing wiki account, and continue. + +This is basically the same model that Mozilla Persona encourages, +except using emailauth ourselves instead of outsourcing (the equivalent +of) that step to Mozilla. + +Thoughts? + +--[[smcv]] From 20d8557c7bff61a7ba58c85a1bfac675c840cbb7 Mon Sep 17 00:00:00 2001 From: smcv Date: Thu, 14 May 2015 06:05:58 -0400 Subject: [PATCH 2/5] please do cloak email addresses, the principle of least astonishment applies --- doc/todo/emailauth.mdwn | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/doc/todo/emailauth.mdwn b/doc/todo/emailauth.mdwn index aac2c988e..4cf2e48e5 100644 --- a/doc/todo/emailauth.mdwn +++ b/doc/todo/emailauth.mdwn @@ -112,3 +112,23 @@ Thoughts anyone? --[[Joey]] >> >> Of course, spammers can troll git repos for emails anyway, so maybe >> this is fine. --[[Joey]] + +>>> I'm not so sure this is OK: user expectations for "a random wiki/blog" +>>> are not the same as for direct git contributions. Common practice for +>>> websites is for email addresses to be only available to the site owner +>>> and/or outsourced services - if ikiwiki doesn't work like this, +>>> I think wiki contributors/blog commenters are going to blame ikiwiki, +>>> not themselves. +>>> +>>> One way to avoid this would be to +>>> [[separate authentication from authorization]], so our account names +>>> would be smcv and joey even on a purely emailauth wiki, with the +>>> fact that we authenticate via email being an implementation detail. +>>> +>>> Another way to do it would be to hash the email address, +>>> so the commit appears to come from +>>> `smcv ` instead of +>>> from `smcv ` - if the hash is of `mailto:whatever` +>>> (like my example one) then it's compatible with +>>> [FOAF](http://xmlns.com/foaf/spec/#term_mbox_sha1sum). +>>> --[[smcv]] From 71ddaa5adb24cc4ba0d771660ef169de4efe16b9 Mon Sep 17 00:00:00 2001 From: kjs Date: Thu, 14 May 2015 07:06:43 -0400 Subject: [PATCH 3/5] --- doc/todo/CSS:_Remove_fixed_height_from_actions.ul.mdwn | 3 +++ 1 file changed, 3 insertions(+) create mode 100644 doc/todo/CSS:_Remove_fixed_height_from_actions.ul.mdwn diff --git a/doc/todo/CSS:_Remove_fixed_height_from_actions.ul.mdwn b/doc/todo/CSS:_Remove_fixed_height_from_actions.ul.mdwn new file mode 100644 index 000000000..44fa05679 --- /dev/null +++ b/doc/todo/CSS:_Remove_fixed_height_from_actions.ul.mdwn @@ -0,0 +1,3 @@ +[[!template id=gitbranch branch=kjs/mobistyle author="[[kjs]]"]] +Currently the bottom border cuts through the text on small devices. Resize your window to a narrow column to check. + From dd1dceef4741debd07b7f7e0cb5715023d6a7587 Mon Sep 17 00:00:00 2001 From: kjs Date: Thu, 14 May 2015 08:14:37 -0400 Subject: [PATCH 4/5] Critical of automatic merging of stylesheets --- doc/todo/concatenating_or_compiling_CSS.mdwn | 22 ++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/doc/todo/concatenating_or_compiling_CSS.mdwn b/doc/todo/concatenating_or_compiling_CSS.mdwn index 068be9398..8f35fb552 100644 --- a/doc/todo/concatenating_or_compiling_CSS.mdwn +++ b/doc/todo/concatenating_or_compiling_CSS.mdwn @@ -157,3 +157,25 @@ this without that feature initially. >>> >>> As you pointed out, CSS inclusion is more painful than it should be, and >>> your proposal seems to answer that. Go ahead! --[[Louis|spalax]] + +> Concatenating the theme css as is done now results in files that are +> unecessarily large with a doubling of a lot of selectors etc. It only makes +> sense for changes that should be local.css anyway. Catted css is inefficient +> both while downloading and while rendering. I've disabled the catting in the +> makefile to avoid this on my personal site. In my view it would be better for +> theme developers to work from the basewiki style, if lazy just add their +> changes to the end of it, or if speed is of secondary importance @import it. +> +> The advanced melding of stylesheets discussed sounds quite complicated with +> likely useability problems when the site don't quite look as expected. Hunting +> down the problematic css will be difficult. +> +> Are there parsers that remove double defined selectors according to cascading +> rules as is done in browser? This would at least produce cleaner css but the +> useability problems would remain. +> +> When using complete themes and hunting that last bit of speed a config option +> to turn off local.css would probably be a good idea? Plugin css is difficult. +> A choice between a plugin complete theme or a local.css (or @import from it) +> would be a simple solution that lets you choose how you prioritize speed +> vs convenience. --[[kjs]] From 7ef44d84d69d11cb16619abcb7eaff5e833e0ace Mon Sep 17 00:00:00 2001 From: "https://id.koumbit.net/anarcat" Date: Thu, 14 May 2015 08:22:29 -0400 Subject: [PATCH 5/5] acls and expectations --- doc/todo/separate_authentication_from_authorization.mdwn | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/doc/todo/separate_authentication_from_authorization.mdwn b/doc/todo/separate_authentication_from_authorization.mdwn index b4a3604ea..4a602babf 100644 --- a/doc/todo/separate_authentication_from_authorization.mdwn +++ b/doc/todo/separate_authentication_from_authorization.mdwn @@ -90,3 +90,7 @@ of) that step to Mozilla. Thoughts? --[[smcv]] + +> I always find it a little ackward that i have two different accounts on this wiki: one for OpenID, and the other (regular account) for email notifications (because of [[bugs/notifyemail_fails_with_some_openid_providers/]]). It seems to me those accounts should just be merged as one, ie. I was expecting to be able to choose a username when i registered with openid. +> +> Also, when you talk about "separating authentication from authorization", i immediately thought of [[todo/ACL/]] and [[todo/Zoned_ikiwiki/]], so i thought i could mention those... having stability in the usernames would help in the design of those... --[[anarcat]]