urosm
/
ikiwiki
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

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

master
Joey Hess 2010-09-26 22:27:50 -04:00
parent 1883e31de2 759260f7c8
commit e789cb9c84
4 changed files with 47 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
doc/bugs/htmlbalance_fails_with_HTML-Tree_v4.mdwn 100644
View File

@ -0,0 +1,16 @@
[[!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:
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.
--[[smcv]]

2
doc/news/openid.mdwn
View File

@ -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"]]

4
doc/news/openid/discussion.mdwn
View File

@ -90,3 +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...

26
doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn
View File

@ -56,3 +56,29 @@ 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)
--[[smcv]]