Merge branch 'master' of ssh://git.ikiwiki.info

4 files changed, 141 insertions, 0 deletions

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.
+
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]]
diff --git a/doc/todo/emailauth.mdwn b/doc/todo/emailauth.mdwn
index 88096bee1..357a4ad9b 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 <smcv@dc84925053b18a910f4b95fb7ce1bf802eb7d80e>` instead of
+>>> from `smcv <smcv@debian.org>` - 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]]
diff --git a/doc/todo/separate_authentication_from_authorization.mdwn b/doc/todo/separate_authentication_from_authorization.mdwn
new file mode 100644
index 000000000..4a602babf
--- /dev/null
+++ b/doc/todo/separate_authentication_from_authorization.mdwn
@@ -0,0 +1,96 @@
+[[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]]
+
+> 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]]