On my (this) website I require new users to validate their e-mails by following the confirmation URLs, which get sent to them... This is a popular approach, which is known to work to protect sites from spammers.
I also allow signing in using OpenID. For this authentication type I prefer to trust OpenID providers, most of which use at least the same e-mail confirmation approach. So I just avoid asking users to confirm their e-mails for another website...
But who said, that any OpenID provider can be trusted?.. Of course, it can be, when we speak about, e.g., Google, but not any OpenID provider! In fact, a dummy OpenID provider can be easily created by spammers (I guess). In this case they would be able to use non-existent emails and would be able to create any number of user accounts on my website. I was really lucky, that they had not done this yet!..
But “luck is what happens when preparation meets opportunity” (Seneca)! Therefore the version 0.2.0 makes a “preparation” for preventing this vulnerability from being exploited further. Thus, it implements the OpenID provider white list:
Here you see URLs of the allowed OpenID providers. Any provider in the list can be temporary disabled by unchecking the Active link in the provider edit form. New providers can be easily added by clicking the “New OpenID source” link in the contextual top right menu. URLs of the provider can contain
*, that means a custom part of the URL (some providers put , e.g., the user name there). The plugin comes with the default list of providers, which includes all providers used in the OpenID Selector plugin, that was written by Jorge Barata González (I personally use it too).
As, in my opinion, it’s a severe security issue (that potentially lets anyone bypass the email verification) I decided to turn the OpenID provider verification on by default. This means, that some of your users can become unable to sign in, if they use some peculiar OpenID provider... Maybe, it’s not good to set the default value this way, but I could not find any better way to draw your attention to the issue. Sorry!
So, after installing or upgrading this plugin you may need to check and update the OpenID provider white list. Either way, !
If, however, you would like to restore the previous behavior (which was in previous versions of the plugin) – i.e., do no verification – you can just disable the Verify OpenID URL option in Administration → Plugins → OpenID → Configure. However, ! Consider setting the Self-registration option to “account activation by email” or “manual account activation”, if you still want to use no OpenID URL verification.
You can also help collecting patterns for OpenID providers by adding your peculiar OpenID source’s settings to this forum.
In fact, before Rostislav reported the issue I had discussions with a few other users on, for example, why don’t I allow activation by email for OpenID registration. All these questions (including the Rostislav’s issue) made me revise the behavior of the plugin and, therefore, as a solution, this release comes with the plugin’s configuration, which contains just one setting:
This setting allows to override the self-registration configuration for OpenID users. To use the default system setting (which can be found in Administration → Settings → Authentication) select "(No change)” here.
By default the OpenID Fix plugin preserves the old behavior, that is, uses the manual activation, if it is selected in Redmine settings, and the automatic activation otherwise. So you should not worry, that the behavior will change on the plugin’s update.
In addition to the above things this release comes with a long-waited support for Redmine 1.4.x, 2.0.x, 2.1.x and 2.2.x (yeah, it was a long time I did not update the plugin).
Also taking the opportunity, I want to draw your attention to the feature, which can come with one of next releases – see #2113. It’s about restricting access to OpenID providers, that is, about controlling, which OpenID providers are allowed to be used by your users for logging in. Please share your thoughts on it!
Generally, you have, perhaps, noticed, that my work on my Redmine plugins has slowed down dramatically recently. The reason for the slow-down was my work on another project for Redmine – I was working on the “Mastering Redmine” book, which was just published and which can be bought now using this link. Now I got back to work on the plugins!
Also reminding you, that you can be among the first, who will know about major events on the OpenID Fix project, by subscribing to it using the subscription form on the sidebar.
Having created this plugin I thought that I would perhaps never update it... It’s too small and too complete! But thanks to Bynn Ies who have found a bug (#1966) in this plugin you can now download its new version.
The previous version of the plugin supported only automatic activation i.e. anyone who was able to login into OpenID provider was about to get access to Redmine. While usually it’s not a problem some administrators may need to control who is having access...
Redmine supports three options of new account activation: a) automatic (was the only one supported by this plugin before), b) manual (support for which has been added) and c) email activation. Only email activation is not supported by this plugin and is not planned to be supported as I assume that you trust OpenID providers enough not to validate user emails provided by them. But if you believe that support for email activation still needs to be added please file a bug report and explain why do you think so.
As I usually recently do in news... I suggest you to subscribe to this project using the form on the sidebar. This form is added by my Subscription plugin which is going to be released soon...
A fix of OpenID authentication in Redmine and ChiliProject was earlier available as a feature of the Extended Profile plugin. Now when the Extended Profile plugin has been divided into two plugins (the Extended Fields and the Extended Profile) the fix has been moved to the separate plugin!
Also available in: Atom