aboutsummaryrefslogtreecommitdiff
path: root/IkiWiki/Plugin/passwordauth.pm
Commit message (Collapse)AuthorAge
* add and use cgiurl_abs_sameschemeJoey Hess2018-01-05
| | | | | | | | | | | | | | | | * emailauth: Fix cookie problem when user is on https and the cgiurl uses http, by making the emailed login link use https. * passwordauth: Use https for emailed password reset link when user is on https. Not entirely happy with this approach, but I don't currently see a better one. I have not verified that the passwordauth change fixes any problem, other than the user getting a http link when they were using https. The emailauth problem is verified fixed by this commit. This commit was sponsored by Michael Magin.
* emailauth, passwordauth: Avoid leaving cgisess_* files in the system temp ↵Joey Hess2017-08-23
| | | | | | | | | | | | | directory. Due to the use/abuse of CGI::Session to generate a token for the login process, a new session database was created for each login, and left behind afterwards. While each file is small, with many logings this could bloat the size of /tmp significantly. Fixed by making CGI::Session write to /dev/null, since there does not seem to be a way to entirely prevent the writing. This commit was sponsored by Henrik Riomar on Patreon.
* CGI, attachment, passwordauth: harden against repeated parametersSimon McVittie2017-01-11
| | | | | | | | | | These instances of code similar to OVE-20170111-0001 are not believed to be exploitable, because defined(), length(), setpassword(), userinfo_set() and the binary "." operator all have prototypes that force the relevant argument to be evaluated in scalar context. However, using a safer idiom makes mistakes less likely. (cherry picked from commit 69230a2220f673c66b5ab875bfc759b32a241c0d)
* passwordauth: avoid userinfo forgery via repeated email parameterSimon McVittie2017-01-11
| | | | | | OVE-20170111-0001 (cherry picked from commit bffb71d6a7d28f6dd5f0be241f214e79eea7bb91)
* passwordauth: prevent authentication bypass via multiple name parametersSimon McVittie2017-01-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Calling CGI::FormBuilder::field with a name argument in list context returns zero or more user-specified values of the named field, even if that field was not declared as supporting multiple values. Passing the result of field as a function parameter counts as list context. This is the same bad behaviour that is now discouraged for CGI::param. In this case we pass the multiple values to CGI::Session::param. That accessor has six possible calling conventions, of which four are documented. If an attacker passes (2*n + 1) values for the 'name' field, for example name=a&name=b&name=c, we end up in one of the undocumented calling conventions for param: # equivalent to: (name => 'a', b => 'c') $session->param('name', 'a', 'b', 'c') and the 'b' session parameter is unexpectedly set to an attacker-specified value. In particular, if an attacker "bob" specifies name=bob&name=name&name=alice, then authentication is carried out for "bob" but the CGI::Session ends up containing {name => 'alice'}, an authentication bypass vulnerability. This vulnerability is tracked as OVE-20170111-0001. (cherry picked from commit e909eb93f4530a175d622360a8433e833ecf0254)
* Use rel=nofollow microformat for dynamic (CGI-related) URLsSimon McVittie2017-01-09
| | | | | | | Some of these might be relatively expensive to dereference or result in messages being logged, and there's no reason why a search engine should need to index them. (In particular, we'd probably prefer search engines to index the rendered page, not its source code.)
* Force CGI::FormBuilder->field to scalar context where necessarySimon McVittie2016-12-28
| | | | | | | | | | | | | | | | | | | | | | | | | | CGI::FormBuilder->field has behaviour similar to the CGI.pm misfeature we avoided in f4ec7b0. Force it into scalar context where it is used in an argument list. This prevents two (relatively minor) commit metadata forgery vulnerabilities: * In the comments plugin, an attacker who was able to post a comment could give it a user-specified author and author-URL even if the wiki configuration did not allow for that, by crafting multiple values to other fields. * In the editpage plugin, an attacker who was able to edit a page could potentially forge commit authorship by crafting multiple values for the rcsinfo field. The remaining plugins changed in this commit appear to have been protected by use of explicit scalar prototypes for the called functions, but have been changed anyway to make them more obviously correct. In particular, checkpassword() in passwordauth has a known prototype, so an attacker cannot trick it into treating multiple values of the name field as being the username, password and field to check for. OVE-20161226-0001
* passwordauth: Don't allow registering accounts that look like openids.Joey Hess2015-05-14
| | | | | Also prohibit @ in account names, in case the file regexp was relaxed to allow it.
* avoid showing password prefs for emailauth userJoey Hess2015-05-13
|
* allow users to subscribe to comments w/o registeringJoey Hess2012-04-02
| | | | | | | | | | Technically, when the user does this, a passwordless account is created for them. The notify mails include a login url, and once logged in that way, the user can enter a password to get a regular account (although one with an annoying username). This all requires the passwordauth plugin is enabled. A future enhancement could be to split the passwordless user concept out into a separate plugin.
* support do=tokenauth login for passwordless accountsJoey Hess2012-04-02
|
* passwordauth: Fix url in password recovery email to be absolute.Joey Hess2012-04-02
| | | | | This got broken when cgiurl began often returning a relative url. Added a cgiurl_abs for the things that need a guaranteed absolute cgiurl.
* add support for a passwordless login tokenJoey Hess2012-04-02
| | | | | | | | | The plan is to use this for accounts that are created implicitly, as when a non-logged-in user subscribes to notifyemail. Such an account has no password, and login can be accomplished by way of a url that is sent to them in email. When the user sets a password, the passwordless login token is disabled.
* fix another undef/"" confusionJoey Hess2012-03-28
|
* stop using REMOTE_ADDRJoey Hess2010-06-23
| | | | | | | | | | | Everywhere that REMOTE_ADDR was used, a session object is available, so instead use its remote_addr method. In IkiWiki::Receive, stop setting a dummy REMOTE_ADDR. Note that it's possible for a session cookie to be obtained using one IP address, and then used from another IP. In this case, the first IP will now be used. I think that should be ok.
* fix uninitialized value warningJoey Hess2010-04-20
| | | | | | $cgi->params('do') may not be defined. The CSRF code may delete all cgi params. This uninitalized value was introduced when do=register support was added recently.
* Group related plugins into sections in the setup file, and drop unused rcs ↵Joey Hess2010-02-11
| | | | plugins from the setup file.
* factor out a userpage functionJoey Hess2010-02-04
| | | | Not yet exported, as only 4 quite core plugins use it.
* Add link to userpage (or creation link) to top of preferences page.Joey Hess2010-02-04
|
* typoJoey Hess2010-02-04
|
* Improve display of openid in preferences page.Joey Hess2010-02-04
| | | | | | | | | Now that openiduser is in IkiWiki core, it's ok to have passwordauth check for it, and avoid displaying useless password fields when showing preferences for an openid. Also improved the styling of the display of the openid in the preferneces page.
* Allow jumping directly into account registration process by going to ↵Joey Hess2010-02-04
| | | | ikiwiki.cgi?do=register
* Disable the Preferences link if no plugin with an auth hook is enabled.Joey Hess2009-06-09
|
* finalise version 3.00 of the plugin apiJoey Hess2008-12-23
|
* Coding style change: Remove explcit vim folding markers.Joey Hess2008-12-17
|
* add plugin safe/rebuild info (part 2 of 3)Joey Hess2008-08-03
| | | | (brain.. melting..)
* remove default values in getsetupJoey Hess2008-07-26
| | | | | They were a bit confusing, since they did not actually set the default, and example values are sufficient.
* typoJoey Hess2008-07-26
|
* adminemail may be undefinedJoey Hess2008-07-26
|
* allow account_creation_password to not be definedJoey Hess2008-07-26
|
* added getsetup hooks for all plugins up to recentchangesJoey Hess2008-07-25
|
* hashed password support, and empty password security fixJoey Hess2008-05-30
| | | | | | | This implements the previously documented hashed password support. While implementing that, I noticed a security hole, which this commit also fixes..
* * Change formbuilder hook to not be responsible for displaying a form,Joey Hess2007-12-12
| | | | | | so that more than one plugin can use this hook. I believe this is a safe change, since only passwordauth uses this hook. (If some other plugin already used it, it would have broken passwordauth!)
* * Fix some bugs in password handling:joey2007-05-17
| | | | | | - If the password is empty in preferences, don't clear the existing password. - Actually check the confirm password field, even if it's left empty.
* * Add an account-creation password as a simple anti-spam mechanism. Ifjoshtriplett2007-05-09
| | | | | set in the wiki setup, passwordauth will require the password in order to create an account.
* * Fix a bug that prevented clearing email or subscriptions.joey2007-04-30
|
* correct size of name field in initial login form (same size as password)joey2007-04-30
|
* Revert passwordauth fieldset and doc to avoid 2.0 regressions; need to ↵joshtriplett2007-04-30
| | | | re-evaluate after 2.0.
* * Group passwordauth fields with a fieldset as well. Add a newjoshtriplett2007-04-30
| | | | | | | | passwordauth page to the basewiki describing password authentication; like openid, it uses conditional to check which forms of authentication the wiki allows. Add conditional cross- links between the openid and passwordauth pages, to help the user understand how they can log in.
* I don't think this comment adds muchjoey2007-04-29
|
* * Use fieldsets in the preferences form to group related options together.joey2007-04-29
| | | | Especially cleans up the ordering of the admin's preferences form.
* * pagespec_match() has changed to take named parameters, to better allowjoey2007-04-27
| | | | | | | | | for extended pagespecs. The old calling convention will still work for back-compat for now. * The calling convention for functions in the IkiWiki::PageSpec namespace has changed so they are passed named parameters. * Plugin interface version increased to 2.00 since I don't anticipate any more interface changes before 2.0.
* * Many changes to make ikiwiki very resistant to write failuresjoey2007-02-15
| | | | | | | | including out of disk space situations. ikiwiki should never leave truncated files, and if the error occurs during a web-based file edit, the user will be given an opportunity to retry. Inspired by the many ways Moin Moin destroys itself when out of disk. :-) * Fix syslogging of errors.
* missing IkiWiki::joey2007-02-03
|
* * Add canedit hook, allowing arbitrary controls over when a page can bejoey2007-02-02
| | | | | | | | | | | | | edited. * Move code forcing signing before edit to a new "signinedit" plugin, and code checking for locked pages into a new "lockedit" plugin. Both are enabled by default. * Remove the anonok config setting. This is now implemented by a new "anonok" plugin. Anyone with a wiki allowing anonymous edits should change their configs to enable this new plugin. * Add an opendiscussion plugin that allows anonymous users to edit discussion pages, on a wiki that is otherwise wouldn't allow it. * Lots of CGI code reorg and cleanup.
* * Initial work on internationalization of the program code. po/ikiwiki.potjoey2006-12-29
| | | | | is available for translation. * Export gettext() from IkiWiki module.
* bugfixenjoey2006-11-22
|
* addjoey2006-11-20