On 06/06/13 05:23, Chris Steipp wrote:
On Tue, Jun 4, 2013 at 9:00 PM, Tyler Romeo tylerro...@gmail.com wrote:
I'm sure you did, but it's kind of useless if nobody provides an
explanation. Do you really expect me to just accept that some WMF
engineers somewhere decided it was best?
I
On 06/06/13 07:14, Daniel Friesen wrote:
You'll need:
* A list of rights to omit and just automatically grant (minoredit,
etc...).
* A map of rights naming what group they belong to.
* A rule to remove read from the list when the wiki is public and a
hook to let extensions do similar with
On Fri, Jun 7, 2013 at 2:58 AM, Tim Starling tstarl...@wikimedia.orgwrote:
I'm recommending making these groups of rights be both a UI concept
and a storage concept, very similar to the existing group feature,
rather than storing right grants and somehow bidirectionally mapping
them to group
On Tue, 04 Jun 2013 18:50:38 -0700, Brad Jorsch bjor...@wikimedia.org
wrote:
On Tue, Jun 4, 2013 at 7:56 PM, Tyler Romeo tylerro...@gmail.com wrote:
If you go by module, then you have problems where you need to grant
specific rights for using modules like list=categorymembers and
On Jun 5, 2013 12:00 AM, Tyler Romeo tylerro...@gmail.com wrote:
I'm sure you did, but it's kind of useless if nobody provides an
explanation. Do you really expect me to just accept that some WMF
engineers somewhere decided it was best?
Your original message seemed to me to assume we were all
On Jun 5, 2013 3:48 AM, Daniel Friesen dan...@nadir-seen-fire.com wrote:
but you can't grant the ability to edit normal pages without also
granting the ability to edit your user CSS/JS
We only need to introduce one (well two if you separate js and css) more
right to restrict that. Then that
On Tue, Jun 4, 2013 at 9:00 PM, Tyler Romeo tylerro...@gmail.com wrote:
I'm sure you did, but it's kind of useless if nobody provides an
explanation. Do you really expect me to just accept that some WMF
engineers somewhere decided it was best?
I should have logged and posted our irc chats
On Wed, 05 Jun 2013 06:42:52 -0700, Brad Jorsch bjor...@wikimedia.org
wrote:
On Jun 5, 2013 3:48 AM, Daniel Friesen dan...@nadir-seen-fire.com
wrote:
There's nothing wrong with having a large list of fine-grained rights to
grant as long as you format them properly for the user.
In other
On Wed, Jun 5, 2013 at 3:23 PM, Chris Steipp cste...@wikimedia.org wrote:
I should have logged and posted our irc chats around this, but I
didn't think of that at the time. That's my fault. I'll try and
reconstruct the discussions we had on wiki.
Thank you. This will also be helpful should
On 05/06/13 15:42, Brad Jorsch wrote:
There's nothing wrong with having a large list of fine-grained rights to
grant as long as you format them properly for the user.
In other words, implement another rights-grouping system just as
complicated and less clear than the approach currently
This schedule is excellent news.
I am working on integrating Moodle with mediawiki and having a Sul support
would be great.
we are looking at two basic use cases.
1. Allowing existing user to log into Moodle via openid.
2. Making edits such as clearing the sandbox on behalf of students.
On 06/04/2013 07:42 AM, oren bochman wrote:
This schedule is excellent news.
I am working on integrating Moodle with mediawiki and having a Sul support
would be great.
we are looking at two basic use cases.
1. Allowing existing user to log into Moodle via openid.
2. Making edits such
On Tue, Jun 4, 2013 at 3:38 PM, Matthew Flaschen mflasc...@wikimedia.orgwrote:
See
https://www.mediawiki.org/wiki/OAuth#Suggested_Granularity_of_Permissions(list
is not final).
Who wrote this? Some interesting excerpts:
- Third party app's code *must* be free software or at least open
On 06/04/2013 06:13 PM, Tyler Romeo wrote:
- Third party app's code *must* be free software or at least open
source (up for debate)
In other words, if you want to make a closed source Wikipedia app, it has
to be insecure.
Could you clarify this? I haven't been following this debate
On Tue, Jun 4, 2013 at 7:11 PM, Mark A. Hershberger m...@everybody.orgwrote:
Could you clarify this? I haven't been following this debate closely
(real life has intervened) but this seems strange to me.
Of course, we can't control the license anyone puts on their code, but
saying that if
On 05/06/13 01:17, Tyler Romeo wrote:
By saying you can only use OAuth if you're open source, it's the same as
saying if you're closed source you must use insecure authentication
methods. Because just saying OAuth must be open source isn't going to stop
closed source developers.
Yes, of
On Tue, Jun 4, 2013 at 7:31 PM, Platonides platoni...@gmail.com wrote:
Yes, of course. It makes no sense. I changed it to a _should_ in the wiki
page
Thanks. I figure it was just written quickly during brainstorming.
*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in
On Tue, Jun 4, 2013 at 4:31 PM, Platonides platoni...@gmail.com wrote:
On 05/06/13 01:17, Tyler Romeo wrote:
By saying you can only use OAuth if you're open source, it's the same as
saying if you're closed source you must use insecure authentication
methods. Because just saying OAuth must be
On Tue, Jun 4, 2013 at 7:46 PM, Rob Lanphier ro...@wikimedia.org wrote:
This page is more relevant to our immediate plans:
https://www.mediawiki.org/wiki/Auth_systems/OAuth
I would be really happy to see someone do some cleanup of this page,
archive the bits written in 2011, and make the
On Tue, Jun 4, 2013 at 4:56 PM, Tyler Romeo tylerro...@gmail.com wrote:
On Tue, Jun 4, 2013 at 7:46 PM, Rob Lanphier ro...@wikimedia.org wrote:
This page is more relevant to our immediate plans:
https://www.mediawiki.org/wiki/Auth_systems/OAuth
I would be really happy to see someone do some
On Tue, Jun 4, 2013 at 8:35 PM, Chris Steipp cste...@wikimedia.org wrote:
We initially were going to use your patch and limit based on module,
but there were a few places where that seemed too course. But then if
we just used user rights, then to edit a page the user needed to grant
8 (iirc)
On 05/06/13 02:37, Tyler Romeo wrote:
On Tue, Jun 4, 2013 at 8:35 PM, Chris Steippcste...@wikimedia.org wrote:
We initially were going to use your patch and limit based on module,
but there were a few places where that seemed too course. But then if
we just used user rights, then to edit a
On Tue, 04 Jun 2013 17:35:24 -0700, Chris Steipp cste...@wikimedia.org
wrote:
The biggest issue we hit with the permissions was trying to balance
fine granularity and not overwhelming the user with the list of what
was being requested and have them blindly agree to it.
We initially were
On Tue, Jun 4, 2013 at 7:56 PM, Tyler Romeo tylerro...@gmail.com wrote:
Why?! What exactly is so bad about just using our own permissions, which
already exists, as the permissions for OAuth tokens. It allows the highest
level of granularity for permissions and allows us to easily display to the
On 06/04/2013 06:13 PM, Tyler Romeo wrote:
- Rollback of all the actions by an individual application should be
possible.
Yeah, if they mean a single rollback FooApp button, that's probably
not going to happen.
Matt Flaschen
___
Wikitech-l
On Tue, Jun 4, 2013 at 9:50 PM, Brad Jorsch bjor...@wikimedia.org wrote:
No, it doesn't. You think we didn't discuss this already?
I'm sure you did, but it's kind of useless if nobody provides an
explanation. Do you really expect me to just accept that some WMF
engineers somewhere decided it
On 06/04/2013 09:48 PM, Daniel Friesen wrote:
Next autoconfirmed. This one you might just filter out to. Does anyone
know of any situation you'd expect OAuth to let an app Edit any page I
can edit, but not the semi-protected ones I could usually edit.?
edit, createpage, and createtalk can
On Mon, 03 Jun 2013 19:43:28 -0700, Tyler Romeo tylerro...@gmail.com
wrote:
On Mon, Jun 3, 2013 at 8:18 PM, Chris Steipp cste...@wikimedia.org
wrote:
We are trying to finish the items in scope (SUL rework, OAuth, and a
review of the OpenID extension) by the end of this month.
Speaking
28 matches
Mail list logo
