The problem is that the current system cannot handle multiple
authentication or authorization sources at once. Furthermore, the system
for granting and blocking permissions is ridiculously crude. This new
system I proposed would allow more flexibility and security for
authentication and authorizati
On Fri, Oct 12, 2012 at 2:14 AM, Seb35 wrote:
> If there are multiple identification sources, what about unicity of
> usernames? i.e. who is User1 if it exists different people User1@OpenID and
> User1@RADIUS? the first who registers on the wiki? or is it assumed all
> User1 are the same people?
>
I like most of the requirements that Tyler and Danial have listed.
There are a couple of things that I didn't clearly see accounted for,
so I wanted to make sure whatever you come up with accounts for these:
- Extensions / tools need to hook into all the identity pieces, so a
tool like AbuseFilter
If there are multiple identification sources, what about unicity of
usernames? i.e. who is User1 if it exists different people User1@OpenID
and User1@RADIUS? the first who registers on the wiki? or is it assumed
all User1 are the same people?
And if there is a rewrite of the auth, I want ju
I don't think it's possible, or even preferable, to do a rework. AuthPlugin
is fundamentally flawed in its design and ExternalAuth is lacking in a
number of major features. What we need is a full-fledged authnz system.
Attached is a basic outline I've been developing recently.
The idea is a very r
On Thu, Oct 11, 2012 at 4:33 PM, Daniel Friesen
wrote:
> I was thinking about this recently too. Though I started thinking from the
> login form perspective.
>
> Things we should have:
> - Good build-in support for both single-authentication (everyone is in the
> user database, or everyone in ldap
I was thinking about this recently too. Though I started thinking from the
login form perspective.
Things we should have:
- Good build-in support for both single-authentication (everyone is in the
user database, or everyone in ldap, etc...) and multi-authentication (some
users are local, so
I'll work on that over the next week and see if I can come up with a good
design to work off of.
*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com
On Thu, Oct 11, 2012 at 2:39 PM, Ryan Lane wrote:
> > I'm ne
> I'm new on this list but found that the last thread about ExternalAuth [1]
> dated back from 2010 [2] but I thought it was acceptable to bring up
> the subject again :)
>
ExternalAuth should be dropped from core. It isn't maintained, it only
supports a single type of authentication that's for so
While this patch will support the functionality you are talking about, I
believe a better move would be to actually design a proper authentication
stack. Some sort of $wgAuthn where you can register authentication layers
on a stack. The problem with AuthPlugin and ExternalUser is that they are
both
I've been told that attachment was stripped (was text/x-diff)
Using text/plain now.
diff --git a/includes/specials/SpecialUserlogin.php
b/includes/specials/SpecialUserlogin.php
index 764ff40..940a4b0 100644
--- a/includes/specials/SpecialUserlogin.php
+++ b/includes/specials/SpecialUserlogin.php
@
The problem is that both AuthPlugin and ExternalAuth are pretty hacked
together authentication system and both should be tossed in the garbage and
replaced with a legitimately designed authnz system.
*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.wh
Hi,
I'm new on this list but found that the last thread about ExternalAuth [1]
dated back from 2010 [2] but I thought it was acceptable to bring up
the subject again :)
Stated simply: many AuthPlugin modules stick to using "External
Sessions" for SSO purpose and only implement the "UserLoadFromS
13 matches
Mail list logo
