| Commit message (Collapse) | Author | Age |
... | |
| | |
|
| |
| |
| |
| | |
reproducibility
|
| |
| |
| |
| | |
for #786587 in libcgi-pm-perl)
|
| |
| |
| |
| |
| |
| |
| | |
This avoids nasty surprises on upgrade if a site is using httpauth,
or passwordauth with an account_creation_password, and relying on
only a select group of users being able to edit the site. We can revisit
this for ikiwiki 4.
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
The wikiname can be pretty un-helpful, the user will probably regognise the
url since they were just at it.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
banned_users
This was needed due to emailauth, but I've also wrapped all IP address
exposure in cloak(), although the function doesn't yet cloak IP addresses.
(One IP address I didn't cloak is the one that appears on the password
reset email template. That is expected to be the user's own IP address,
so ok to show it to them.)
Thanks to smcv for the pointer to
http://xmlns.com/foaf/spec/#term_mbox_sha1sum
|
| |
| |
| |
| |
| | |
Also prohibit @ in account names, in case the file regexp was relaxed to
allow it.
|
| |
| |
| |
| |
| |
| | |
There's no real problem if they do change it, except they may get confused
and expect to be able to log in with the changed email and get the same
user account.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
email address
This makes the email not be displayed on the wiki, so spammers won't find
it there.
Note that the full email address is still put into the comment template.
The email is also used as the username of the git commit message
(when posting comments or page edits). May want to revisit this later.
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Still some work to do since the user name is an email address and should
not be leaked.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Now template variables can be set to control which login methods are shown
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This includes some CSS changes to names of elements.
Also, added Email login button (doesn't work yet of course),
and brought back the small openid login buttons. Demoted yahoo and verison
to small buttons. This makes the big buttons be the main login types, and
the small buttons be provider-specific helpers.
|
| |
| |
| |
| | |
openid selector display "Password" instead of "Other", so users are more likely to click on it when they don't have an openid.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
[[forum/refresh_and_setup]] indicates some confusion between --setup
and -setup. Both work, but it's clearer if we stick to one in
documentation and code.
A 2012 commit to [[plugins/theme]] claims that "-setup" is required
and "--setup" won't work, but I cannot find any evidence in ikiwiki's
source code that this has ever been the case.
|
| | |
|
| | |
|
| |
| |
| |
| | |
but don't let this problem crash ikiwiki entirely.
|
| | |
|
| | |
|
| | |
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
According to caniuse.com, a significant fraction of Web users are
still using Internet Explorer versions that do not support HTML5
sectioning elements. However, claiming we're XHTML 1.0 Strict
means we can't use features invented in the last 12 years, even if
they degrade gracefully in older browsers (like the role and placeholder
attributes).
This means our output is no longer valid according to any particular
DTD. Real browsers and other non-validator user-agents have never
cared about DTD compliance anyway, so I don't think this is a real loss.
|
| | | |
|
| | | |
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | | |
config option
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
Thanks to review from http://ikiwiki.info/todo/calendar_autocreate/
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
This is needed for notifyemail, and not all openid providers report an
email address, or necessarily the one the user wants to get email.
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We're running under "use strict" here, so if CGI->param's array-context
misbehaviour passes an extra non-ref parameter, it shouldn't be executed
anyway... but it's as well to be safe.
[commit message added by smcv]
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
CGI->param has the misfeature that it is context-sensitive, and in
particular can expand to more than one scalar in function calls.
This led to a security vulnerability in Bugzilla, and recent versions
of CGI.pm will warn when it is used in this way.
In the situations where we do want to cope with more than one parameter
of the same name, CGI->param_fetch (which always returns an
array-reference) makes the intention clearer.
[commit message added by smcv]
|
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When CGI->param is called in list context, such as in function
parameters, it expands to all the potentially multiple values
of the parameter: for instance, if we parse query string a=b&a=c&d=e
and call func($cgi->param('a')), that's equivalent to func('b', 'c').
Most of the functions we're calling do not expect that.
I do not believe this is an exploitable security vulnerability in
ikiwiki, but it was exploitable in Bugzilla.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
checksessionexpiry's signature changed from
(CGI::Session, CGI->param('sid')) to (CGI, CGI::Session) in commit
985b229b, but editpage still passed the sid as a useless third
parameter, and this was later cargo-culted into remove, rename and
recentchanges.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The intention was that signed-in users (for instance via httpauth,
passwordauth or openid) are already adequately identified, but
there's nothing to indicate who an anonymous commenter is unless
their IP address is recorded.
|
| | |
| | |
| | |
| | | |
This happens for PDFs without ghostscript installed, for instance.
|