Hi all,
I wanted to get some input from you all about any ideas or plans they have
for identifying OAuth user in your applications.
tl;dr, Since lots of people want to do authentication with OAuth, I'm
thinking we'll implement a custom way to get identity information from the
wiki in the near term, and then probably try to implement the OpenID
Connect extension to OAuth 2 sometime next year.
Since we started rolling out OAuth, we've consistently had requests to use
OAuth to authenticate users in other applications, based on their wiki
identity. OAuth does not support this, since the results of an api call
using OAuth signatures aren't signed (only the request from the OAuth
consumer is signed), so it's possible that an attacker could forge a
response back to the application, and the application would think a
different user was logged in. This is less likely if you're using https for
your api calls, but it's surprisingly hard to get https right [1], even if
you trust all your CA's.
We were planning to roll out OpenID this fall to authenticate users, while
OAuth is used for authorizing access into the wiki. Wikinaut has been
working hard on the OpenID extension, but it's not quite ready to deploy
yet. Additionally, with this setup, applications like Snuggle and UTRS that
want to both authenticate users and use OAuth for authorized api requests
have to implement both OpenID and OAuth libraries, which is a pain.
This is a common issue is being addressed by the OpenID Connect extension
to OAuth2, which allows the application to request information about the
person doing the authorization, and the result is signed by the server to
prevent tampering. The standard is still a draft, but it seems like the
correct solution to our pain point, so I think that's the direction we'll
head once the standard is finalized, and we have some time to throw at it.
In the meantime, I'm also thinking we may implement something similar,
where an OAuth consumer can request a signed assertion about the
authorizing user. It would probably use the same format that OpenID Connect
uses (JWT [2]), and use the consumer secret for the hmac signature. This
would let the application check that a user has a specific set of
permission at the time of the call, and would require a lot less
development effort.
Does this seem like a reasonable tradeoff? Assuming we do this direction,
what attributes about the wiki user account should be provided. I was
planning on username, if the account is autoconfirmed, maybe number of
edits, and the list of groups to which the user belongs. Anything else?
[1] -
http://blog.astrumfutura.com/2010/10/do-cryptographic-signatures-beat-ssltl…http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-12
Hey,
The new version of git-review released today (1.22) includes a patch I
wrote that makes it possible to work against a single 'origin' remote. This
amounts to a workaround for git-review's tendency to frighten you into
thinking you're about to submit more patches than the ones you are working
on. It makes git-review more pleasant to work with, in my opinion.
To enable this behavior, you first need to upgrade to the latest version of
git-review, by running "pip install -U git-review". Then you need to create
a configuration file: either /etc/git-review/git-review.conf (system-wide)
or ~/.config/git-review/git-review.conf (user-specific).
The file should contain these two lines:
[gerrit]
defaultremote = origin
Once you've made the change, any new Gerrit repos you clone using an
authenticated URI will just work.
You'll need to perform an additional step to migrate existing repositories.
In each repository, run the following commands:
git remote set-url origin $(git config --get remote.gerrit.url)
git remote rm gerrit
git review -s
Hope you find this useful.
The Wikimedia Foundation's Technical Operations team is seeking proposals on the provisioning of a new data-centre facility.
After working through the specifics internally, we now have a public RFP posted[1] and ready for proposals. We invite any organization meeting the requirements outlined to submit a proposal for review.
Most of the relevant details are in the document itself, but feel free to reach out to myself or the list should anyone have any questions.
Please, feel free to forward this link far and wide - have colleagues, contacts or friends in the data-centre sector? Then please, forward it on! :)
Thanks!
--Ken.
[1] https://wikimediafoundation.org/wiki/RFP/2013_Datacenter
Hello all,
The last week, I've been working on a web interface to upload patches to
Gerrit. This would allow people to contribute, even without using git for
more than 'pull' and 'diff'. One could even use the SVN mirror on github to
update & generate patches.
It uses OAuth to identify the user to prevent abuse, and the OAuth
identified user will be listed as committer name in the commit. The
username shown as 'owner' in Gerrit will still be 'Gerrit patch uploader'.
Another reason this is useful is if you're uploading other people's work -
I find it annoying to have these listed under 'outgoing reviews', as they
are patches I should review, not that I should ask others to review.
It's hosted on Tool Labs: https://tools.wmflabs.org/gerrit-patch-uploader/
Merlijn
Question for the group:
Would an officially supported general-purpose MediaWiki hosting service be
useful to people who would like to run wikis, but don't have the time,
expertise, or resources to maintain their own installation?
If so, what can we (as interested parties in MediaWiki development and use)
do to make this happen?
[Please do not consider the existence of this email to imply that only
regular posters on wikitech-l are allowed to read, comment on, or give
opinions in this matter -- on the contrary, wider input is being requested.
Please forward this question to anyone to whom it may be of interest. If
you would like to get more input from other people, please feel free to
contact them on your own, with or without a forward of this mail, and to
make follow-up posts or comments as you need or want to. Please feel free
to modify the question, the idea, the proposal, or make comments or
additions. Be bold and get involved!]
-- brion
Google Code-in has a category specific to documentation / training
tasks. Can the students of this program help us fixing our Bug #1?
https://www.mediawiki.org/wiki/Google_Code-In#Documentation.2FTraining
Your help identifying tasks is welcome! There is no lack of work to do
in our documentation, both at mediawiki.org (plus other sites) and our code.
Good type of tasks for Google Code-in related to documentation and
training include:
* Fixing typos and other language improvements in mediawiki.org pages.
Do we have a specific category to mark those pages?
* Update documentation.
* Write step-by-step tutorials, or create the corresponding screencasts.
* Illustrate documentation with screenshots.
* Write examples.
Each task should take about 2-3 hours to an experienced contributor
(with the environment all setup, aware of the background...), 2-3 days
to a total newcomer.
Also, having a couple of meta-mentors focusing on documentation related
tasks would be great, and in fact needed.
--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hello,
I will be upgrading Jenkins tomorrow at 8:00UTC for a minor upgrade.
The upgrade should take roughly one hour, during that time any job
launched will be reported as LOST in Gerrit and would need to be
retriggered manually (by editing the commit summary for example).
Thanks!
--
Antoine "hashar" Musso
Hi everyone,
The signup deadline for the Architecture Summit is coming this Tuesday,
October 22, 17:00 UTC (10am PDT). Put your name here:
https://www.mediawiki.org/wiki/Architecture_Summit_2014
More details are at the page above, and the email below.
Rob
---------- Forwarded message ----------
From: Rob Lanphier <robla(a)wikimedia.org>
Date: Tue, Oct 8, 2013 at 4:25 PM
Subject: Sign up for the MediaWiki Architecture Summit (deadline October 22)
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Hi everyone,
Registration for the MediaWiki Architecture Summit is now open, and
will close Tuesday, October 22, 17:00 UTC (10am PDT). Here is the
essential event information:
January 23-24, 2014
SPUR - 654 Mission Street
San Francisco, CA, USA
Please put your name/information on the following wiki page to sign up:
https://www.mediawiki.org/wiki/Architecture_guidelines/Meetings/Architectur…
NOTE: even if you've previously RSVP'd (having received an early
invitation as we were picking dates), please sign up on the page
above. We're requesting information that will help shape the event.
The target audience of this event are mainly project maintainers and
other developers involved in Requests for Comment and, in general, the
future evolution of MediaWiki and related software components. All
participants must specify their current involvement in the MediaWiki
project, the RFC(s) that are promoting and the main future topics they
want to discuss. We are tentatively aiming to have around 50-60
people and we have some budget to sponsor travel for accepted
participants.
Rob