From 4846b4472ec69e95dd2cc0a792aaf7668367263d Mon Sep 17 00:00:00 2001 From: "98.66.223.132" <98.66.223.132@web> Date: Sun, 26 Sep 2010 04:16:56 +0000 Subject: poll vote (Accept both) --- doc/news/openid.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/news/openid.mdwn b/doc/news/openid.mdwn index 67bf10cb6..32325559e 100644 --- a/doc/news/openid.mdwn +++ b/doc/news/openid.mdwn @@ -10,4 +10,4 @@ log back in, try out the OpenID signup process if you don't already have an OpenID, and see how OpenID works for you. And let me know your feelings about making such a switch. --[[Joey]] -[[!poll 66 "Accept only OpenID for logins" 21 "Accept only password logins" 36 "Accept both"]] +[[!poll 66 "Accept only OpenID for logins" 21 "Accept only password logins" 37 "Accept both"]] -- cgit v1.2.3 From 954b6353b029062418b911114baa9f86b216e44e Mon Sep 17 00:00:00 2001 From: "http://lovesgoodfood.com/jason/" Date: Sun, 26 Sep 2010 04:18:15 +0000 Subject: --- doc/news/openid/discussion.mdwn | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/news/openid/discussion.mdwn b/doc/news/openid/discussion.mdwn index c0447a13f..fdd5eecd1 100644 --- a/doc/news/openid/discussion.mdwn +++ b/doc/news/openid/discussion.mdwn @@ -90,3 +90,5 @@ I just tried logging it with OpenID and it Just Worked. Pretty painless. If yo ###LiveJournal openid One caveat to the above is that, of course, OpenID is a distributed trust system which means you do have to think about the trust aspect. A case in point is livejournal.com whose OpenID implementation is badly broken in one important respect: If a LiveJournal user deletes his or her journal, and a different user registers a journal with the same name (this is actually quite a common occurrence on LiveJournal), they in effect inherit the previous journal owner's identity. LiveJournal does not even have a mechanism in place for a remote site even to detect that a journal has changed hands. It is an extremely dodgy situation which they seem to have *no* intention of fixing, and the bottom line is that the "identity" represented by a *username*.livejournal.com token should not be trusted as to its long-term uniqueness. Just FYI. --[[blipvert]] +---- +Submitting bugs in the OpenID components will be difficult if OpenID must be working first... -- cgit v1.2.3 From 896adeafda0b81227ca54f058b18f7c3aadd318c Mon Sep 17 00:00:00 2001 From: "http://lovesgoodfood.com/jason/" Date: Sun, 26 Sep 2010 04:19:29 +0000 Subject: (fixing silly formatting issue) --- doc/news/openid/discussion.mdwn | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/news/openid/discussion.mdwn b/doc/news/openid/discussion.mdwn index fdd5eecd1..bc9856ad9 100644 --- a/doc/news/openid/discussion.mdwn +++ b/doc/news/openid/discussion.mdwn @@ -90,5 +90,7 @@ I just tried logging it with OpenID and it Just Worked. Pretty painless. If yo ###LiveJournal openid One caveat to the above is that, of course, OpenID is a distributed trust system which means you do have to think about the trust aspect. A case in point is livejournal.com whose OpenID implementation is badly broken in one important respect: If a LiveJournal user deletes his or her journal, and a different user registers a journal with the same name (this is actually quite a common occurrence on LiveJournal), they in effect inherit the previous journal owner's identity. LiveJournal does not even have a mechanism in place for a remote site even to detect that a journal has changed hands. It is an extremely dodgy situation which they seem to have *no* intention of fixing, and the bottom line is that the "identity" represented by a *username*.livejournal.com token should not be trusted as to its long-term uniqueness. Just FYI. --[[blipvert]] + ---- + Submitting bugs in the OpenID components will be difficult if OpenID must be working first... -- cgit v1.2.3 From fd7062959a6c2d301cfc091795e9989d0df94b23 Mon Sep 17 00:00:00 2001 From: "http://smcv.pseudorandom.co.uk/" Date: Sun, 26 Sep 2010 21:39:07 +0000 Subject: HTML::Tree v4 is not entirely backwards-compatible --- doc/bugs/htmlbalance_fails_with_HTML-Tree_v4.mdwn | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 doc/bugs/htmlbalance_fails_with_HTML-Tree_v4.mdwn diff --git a/doc/bugs/htmlbalance_fails_with_HTML-Tree_v4.mdwn b/doc/bugs/htmlbalance_fails_with_HTML-Tree_v4.mdwn new file mode 100644 index 000000000..c02ec114f --- /dev/null +++ b/doc/bugs/htmlbalance_fails_with_HTML-Tree_v4.mdwn @@ -0,0 +1,13 @@ +[[!template id=gitbranch branch=smcv/ready/htmlbalance author="[[smcv]]"]] + +My one-patch htmlbalance branch fixes incompatibility with HTML::Tree 4.0. +From the git commit: + + The HTML::Tree changelog says: + + [THINGS THAT MAY BREAK YOUR CODE OR TESTS] + ... + * Attribute names are now validated in as_XML and invalid names will + cause an error. + + and indeed the regression tests do get an error. -- cgit v1.2.3 From 82d751cf32d14acfaf09edad70e387c28a946145 Mon Sep 17 00:00:00 2001 From: "http://smcv.pseudorandom.co.uk/" Date: Sun, 26 Sep 2010 21:39:47 +0000 Subject: +patch --- doc/bugs/htmlbalance_fails_with_HTML-Tree_v4.mdwn | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/bugs/htmlbalance_fails_with_HTML-Tree_v4.mdwn b/doc/bugs/htmlbalance_fails_with_HTML-Tree_v4.mdwn index c02ec114f..e608e1b3d 100644 --- a/doc/bugs/htmlbalance_fails_with_HTML-Tree_v4.mdwn +++ b/doc/bugs/htmlbalance_fails_with_HTML-Tree_v4.mdwn @@ -11,3 +11,5 @@ From the git commit: cause an error. and indeed the regression tests do get an error. + +[[!tag patch]] -- cgit v1.2.3 From 58c80f8ed1d0dea5e03bc566769522c558353ab8 Mon Sep 17 00:00:00 2001 From: "http://smcv.pseudorandom.co.uk/" Date: Sun, 26 Sep 2010 21:53:00 +0000 Subject: +patch --- ...ttp_or_https_in_urls_to_allow_serving_both.mdwn | 24 ++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn b/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn index 63fd3d11d..d59bf15f0 100644 --- a/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn +++ b/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn @@ -56,3 +56,27 @@ becoming a problem for me. Is there anything I can do here? --[[Perry]] > absolute urls that have been fixed since Brian filed the bug. --[[Joey]] [[wishlist]] + +---- + +[[!template id=gitbranch branch=smcv/https author="[[smcv]]"]] +[[!tag patch]] + +For a while I've been using a configuration where each wiki has a HTTP and +a HTTPS mirror, and updating one automatically updates the other, but +that seems unnecessarily complicated. My `https` branch adds `https_url` +and `https_cgiurl` config options which can be used to provide a HTTPS +variant of an existing site; the CGI script automatically detects whether +it was accessed over HTTPS and switches to the other one. + +This required some refactoring, which might be worth merging even if +you don't like my approach: + +* change `IkiWiki::cgiurl` to return the equivalent of `$config{cgiurl}` if + called with no parameters, and change all plugins to indirect through it + (then I only need to change that one function for the HTTPS hack) + +* `IkiWiki::baseurl` already has similar behaviour, so change nearly all + references to the `$config{url}` to call `baseurl` (a couple of references + specifically wanted the top-level public URL for Google or Blogspam rather + than a URL for the user's browser, so I left those alone) -- cgit v1.2.3 From 9d634e97d2f359db65883aadfb941309a53a0bc8 Mon Sep 17 00:00:00 2001 From: "http://smcv.pseudorandom.co.uk/" Date: Sun, 26 Sep 2010 21:53:54 +0000 Subject: sign my change --- ...avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn b/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn index d59bf15f0..112112284 100644 --- a/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn +++ b/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn @@ -80,3 +80,5 @@ you don't like my approach: references to the `$config{url}` to call `baseurl` (a couple of references specifically wanted the top-level public URL for Google or Blogspam rather than a URL for the user's browser, so I left those alone) + +--[[smcv]] -- cgit v1.2.3 From 759260f7c836f3491d4250e77aea2c14ad9369b5 Mon Sep 17 00:00:00 2001 From: "http://smcv.pseudorandom.co.uk/" Date: Sun, 26 Sep 2010 21:54:32 +0000 Subject: sign --- doc/bugs/htmlbalance_fails_with_HTML-Tree_v4.mdwn | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/doc/bugs/htmlbalance_fails_with_HTML-Tree_v4.mdwn b/doc/bugs/htmlbalance_fails_with_HTML-Tree_v4.mdwn index e608e1b3d..2613224cf 100644 --- a/doc/bugs/htmlbalance_fails_with_HTML-Tree_v4.mdwn +++ b/doc/bugs/htmlbalance_fails_with_HTML-Tree_v4.mdwn @@ -1,4 +1,5 @@ [[!template id=gitbranch branch=smcv/ready/htmlbalance author="[[smcv]]"]] +[[!tag patch]] My one-patch htmlbalance branch fixes incompatibility with HTML::Tree 4.0. From the git commit: @@ -12,4 +13,4 @@ From the git commit: and indeed the regression tests do get an error. -[[!tag patch]] +--[[smcv]] -- cgit v1.2.3