Hoi,
I have re-read the Wikipedia article about OpenID and OpenAuth.
OpenAuth while nice in many ways is NOT the same as OpenID. User
authentication is one easy and obvious requirement and I have already said
too much about its need.
It is NOT clear at all to me why OpenAuth should be regarded
OpenID is an identity management system. It allows users to authenticate to
one site using another site as their identity. A use case for this is, for
example, using your Facebook account to log in to Wikipedia. This may be
useful, as it would allow users to more easily register for Wikipedia.
I have re-read the Wikipedia article about OpenID and OpenAuth.
OpenAuth while nice in many ways is NOT the same as OpenID. User
authentication is one easy and obvious requirement and I have already said
too much about its need.
It is NOT clear at all to me why OpenAuth should be regarded
Bots could also benefit from this greatly.
Indeed. In fact, it could (possibly) even change the way bots are done
altogether. Right now bots are put on separate bot accounts so that if they
are compromised the main user account is still secure (and also so that the
permissions are separated).
On Mon, Aug 27, 2012 at 1:04 PM, Tyler Romeo tylerro...@gmail.com wrote:
Bots could also benefit from this greatly.
Indeed. In fact, it could (possibly) even change the way bots are done
altogether. Right now bots are put on separate bot accounts so that if they
are compromised the main
On Mon, Aug 27, 2012 at 1:08 PM, Chad innocentkil...@gmail.com wrote:
On Mon, Aug 27, 2012 at 1:04 PM, Tyler Romeo tylerro...@gmail.com wrote:
Indeed. In fact, it could (possibly) even change the way bots are done
altogether. Right now bots are put on separate bot accounts so that if they
are
I don't think that's something we really want to do. Granting bot
permissions hides someone from RecentChanges by default,
which you wouldn't want as a normal user (well you might, but
I don't think communities would).
Indeed. Communities also want separate bot accounts so it's easy to
tell
Well, with OAuth, it might be possible to mark actions as bot actions.
It would also be possible to revoke just the OAuth key that allows the
bot to operate, thus avoiding blocking the user.
It would still be easier though for an end user to look at a username and see
the bot. The user pages for
It would still be easier though for an end user to look at a username and see
the bot. The user pages for Bots usually include quite a bit of information
on
them as well. Definitely think replacing Bot accounts with OAuth is the wrong
way to go. I like the idea of using it for the
I agree that bot accounts should still be separate, I just wanted to make
the point that, theoretically, since the permissions are separated, you
could do it that way if so desired.
*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com |
On Fri, 24 Aug 2012 14:14:30 -0700, Daniel Friesen
dan...@nadir-seen-fire.com wrote:
On Fri, 24 Aug 2012 11:24:46 -0700, Chris Steipp cste...@wikimedia.org
wrote:
On Fri, Aug 24, 2012 at 10:33 AM, Nabil Maynard nadr...@gmail.com
wrote:
On Fri, Aug 24, 2012 at 10:16 AM, Tyler Romeo
On 08/24/2012 01:33 PM, Nabil Maynard wrote:
- Persona: Previously called BrowserID. It's come a LONG way in the past
few months, and provides another fairly clean identity/authentication
system.
As a bonus, there is already a BrowserID extension for Bugzilla that
Mozilla is using. Maybe
2012/8/26 Mark A. Hershberger m...@everybody.org:
On 08/24/2012 01:33 PM, Nabil Maynard wrote:
- Persona: Previously called BrowserID. It's come a LONG way in the past
few months, and provides another fairly clean identity/authentication
system.
As a bonus, there is already a BrowserID
If there are issues with the old standard, there is no significant
advantage to use of the old spec (besides the case that it already exists,
etc...), and you are intending to actually use the standard rather than
just throw it out for people to use. Then that's really a valid situation
to
Meta discussions over community, Appreciation threads, GSoC wrapups,
Deployment threads, and orthogonal questions.
Lately wikitech-l seems to be almost void of one of the most important
categories of discussion I like to see here.
Discussions on adding new features to MediaWiki!
So, just
- OAuth: Well not actually OAuth. After getting a full understanding of
this topic
implementation of actual OAuth (12) looks like a dark dead-end. Rather
than OAuth I'd like
to write a new auth standard that learns from all the good things and
the mistakes made in
both versions of OAuth and
On Fri, Aug 24, 2012 at 10:16 AM, Tyler Romeo tylerro...@gmail.com wrote:
- OAuth: Well not actually OAuth. After getting a full understanding of
this topic
implementation of actual OAuth (12) looks like a dark dead-end. Rather
than OAuth I'd like
to write a new auth standard that learns
Meta discussions over community, Appreciation threads, GSoC wrapups,
Deployment threads, and orthogonal questions.
Lately wikitech-l seems to be almost void of one of the most important
categories of discussion I like to see here.
Discussions on adding new features to MediaWiki!
So, just
Wait a second. Concerning the password reset, currently it uses the
user_newpassword field, which means the user is required to reset their
password upon login. How is this any different than using a reset token,
where the user supplies the reset token and changes their password?
*--*
*Tyler
On Fri, Aug 24, 2012 at 1:52 PM, Tyler Romeo tylerro...@gmail.com wrote:
Wait a second. Concerning the password reset, currently it uses the
user_newpassword field, which means the user is required to reset their
password upon login. How is this any different than using a reset token,
where
Yes, but that's only increased convenience. I'm wondering exactly what
security implications there are to our current system v. a token reset
system.
*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com
On Fri,
n 24 August 2012 18:57, Tyler Romeo tylerro...@gmail.com wrote:
Yes, but that's only increased convenience. I'm wondering exactly what
security implications there are to our current system v. a token reset
system.
*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in
The password length is whatever $wgMinimalPasswordLength is set to, and
according to DefaultSettings.php it's 1 :P. Maybe we should increase the
length of passwords from User::randomPassword.
- Security: Because the temporary password is being entered by the user it
ends up being much shorter
The password length is whatever $wgMinimalPasswordLength is set to, and
according to DefaultSettings.php it's 1 :P. Maybe we should increase the
length of passwords from User::randomPassword.
- Security: Because the temporary password is being entered by the user it
ends up being much shorter
On Fri, Aug 24, 2012 at 10:33 AM, Nabil Maynard nadr...@gmail.com wrote:
On Fri, Aug 24, 2012 at 10:16 AM, Tyler Romeo tylerro...@gmail.com wrote:
Not a good idea: http://xkcd.com/927/
While OAuth has its problems, it's not a terrible protocol (or at least v1
isn't).
Seconded -- I'd rather
On Fri, 24 Aug 2012 11:24:46 -0700, Chris Steipp cste...@wikimedia.org
wrote:
On Fri, Aug 24, 2012 at 10:33 AM, Nabil Maynard nadr...@gmail.com
wrote:
On Fri, Aug 24, 2012 at 10:16 AM, Tyler Romeo tylerro...@gmail.com
wrote:
Not a good idea: http://xkcd.com/927/
While OAuth has its
On 8/24/12 12:33 PM, Nabil Maynard wrote:
My personal wishlist:
- Persona: Previously called BrowserID. It's come a LONG way in the past
few months, and provides another fairly clean identity/authentication
system.
That's on Mozilla's wishlist, too!
For background, Persona is an open,
I also thought about implementing Persona (BrowserID) for user login.
Although solving the account model problem by replacing email
addresses with SUL usernames. :)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
Did these organizations need to use those SAML credentials directly for API
things or is this just another method we want to support for logging in?
https://meta.wikimedia.org/wiki/Wikimedia_Fellowships/Project_Ideas/The_Wikipedia_Library
That's the biggest current reason for wanting to
Tyler Romeo wrote:
Wait a second. Concerning the password reset, currently it uses the
user_newpassword field, which means the user is required to reset their
password upon login. How is this any different than using a reset token,
where the user supplies the reset token and changes their
Mailman integration: You just got promoted to sysop / steward /
checkuser/arbcom ?
You now have a new checkbox at [[Special:MailingLists]] for subscribing
to the relevant private list!
(I suggest to add the new ideas as direct children of the root post, and
use other descendents for discussing
On Fri, 24 Aug 2012 15:10:55 -0700, Ryan Lane rlan...@gmail.com wrote:
Did these organizations need to use those SAML credentials directly for
API
things or is this just another method we want to support for logging in?
Oh... so not SAML logins or SAML assertions for the api but acting as a
provider of SAML accounts for logging into a 3rd party source with a
Wikipedia account?
Yeah. It's the more interesting situation at first. I'm sure there are
some interesting use cases the opposite way, but we have an
33 matches
Mail list logo
