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 | t
> 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 too
>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 f
>> 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
On Mon, Aug 27, 2012 at 1:08 PM, Chad wrote:
> On Mon, Aug 27, 2012 at 1:04 PM, Tyler Romeo 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 compromised the main user account is s
On Mon, Aug 27, 2012 at 1:04 PM, Tyler Romeo 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 user account is
>
> 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).
> 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 rega
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.
OAu
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 ov
>
> 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
>
2012/8/26 Mark A. Hershberger :
> 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
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
On Fri, 24 Aug 2012 14:14:30 -0700, Daniel Friesen
wrote:
On Fri, 24 Aug 2012 11:24:46 -0700, Chris Steipp
wrote:
On Fri, Aug 24, 2012 at 10:33 AM, Nabil Maynard
wrote:
On Fri, Aug 24, 2012 at 10:16 AM, Tyler Romeo
wrote:
Not a good idea: http://xkcd.com/927/
While OAuth has its pr
> 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
On Fri, 24 Aug 2012 15:10:55 -0700, Ryan Lane 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?
https://meta.wikimedia.org/wiki/Wikimedia_Fellowships/Project_Ideas/The_Wikipedia_Librar
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 th
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 p
> 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 sup
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
https://lists.wikimedia.org
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, decen
On Fri, 24 Aug 2012 11:24:46 -0700, Chris Steipp
wrote:
On Fri, Aug 24, 2012 at 10:33 AM, Nabil Maynard
wrote:
On Fri, Aug 24, 2012 at 10:16 AM, Tyler Romeo
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).
On Fri, Aug 24, 2012 at 10:33 AM, Nabil Maynard wrote:
> On Fri, Aug 24, 2012 at 10:16 AM, Tyler Romeo 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 see contributions to makin
>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 sho
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 th
- Usability: Forcing the user to manually enter the token is a very bad
user experience. We have good email confirmation tokens but don't bother
to do password resets the same way.
- Security: Because the temporary password is being entered by the user it
ends up being much shorter than it sh
n 24 August 2012 18:57, Tyler Romeo 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 Computer Scie
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, A
On Fri, Aug 24, 2012 at 1:52 PM, 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 t
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 Romeo
>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, j
On Fri, Aug 24, 2012 at 10:16 AM, Tyler Romeo wrote:
> > - OAuth: Well not actually OAuth. After getting a full understanding of
> this topic
> > implementation of actual OAuth (1&2) looks like a dark dead-end. Rather
> than OAuth I'd like
> > to write a new auth standard that learns from all th
> - OAuth: Well not actually OAuth. After getting a full understanding of
this topic
> implementation of actual OAuth (1&2) 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 a
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 lik
34 matches
Mail list logo
