http://phpmentoring.org/
#phpmentoring on Freenode IRC
Mentoring and apprenticing are ways to learn, get recognition, get
advice and find new opportunities, and find role models (or become one).
Check it out.
--
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation
When I edit a page titled "a_b_c",the title always displayed as "a b c".
I have tried to add {{DISPLAYTITLE:"a_b_c"}} in the page but it doesn't
work.
Do I have made some mistake?
Thank all.
Wang
On Monday, July 16, 2012 11:45:07 AM, Achim Flammenkamp wrote:
> It is a question of permission and knowledge.
You have the same permission everyone has: you can modify the code that
runs Wikipedia.
If you don't have the knowledge to make the changes, then why do you
insist that they are only minor modifications?
--
What is normal? Normal is yesterday and last week and
last month taken together.
-- Snuff, Terry Pratchett
Hi
> You should stick around, but you should also understand that your
> request isn't something that Wikimedia is likely to deploy since it
> doesn't meet the needs of a significant part of the Wiki*-using community.
Right. But I thought the relation of effort to usage is important, (not only
the quantity of usage) and mine has a very low effort to implement (measured
in needed real-time), because the things already exist and only needs to be put
in, IMHO. (BTW, I explicitly know at least 4 other guys on wiki (and this is by
chance, I started no search), which also like to see my feature/aim implemented
-- even here people supported it)
> Instead, since this is a tool *you* want, you should look at creating a
> tool that meets your needs. Since a few other people have expressed
I don't call for an SVG-editor. These are other people here, which think I
should! :-( Please, don't tell me what I need to have to want (my needs are),
I think I can decide for myself best myself. :-/
I want to keep in principle everthing for mantaining/administration of SVG-files like any
other text-page-namespace here (storage-philosphy/version-control/diff/editing/...)!
> If you think editing SVGs should be simpler, then I suggest that the
I think editing (as a minor point) should be as every text-namespace here, not
impossible online (all other text-namespaces are simple editable) like now, not
explicitly handled different (less/worse supported). Thus you miss the point.
I dislike to insult, but one should ask why permanently people don't realize
that I don't call for a SVG-editor. They mix up *their thought/idea* with my
(different) aim as if they don't read/understand what I had writen and then
claim I would request the other feature. This happened starting with the very
first message to this topic here. Sorry, to have blamed the big majority of
responses now. :-( I'm really nearly up to resign frustrated because of this
pschologic missbehavior here.
Nevertheless, regards
Achim
[Sorry Mark for sending you this twice]
Hello new developer comrades,
The following line in my .vimrc file has given me back some form of
happiness that I thought I had lost after several weeks of switching tab
settings every time I might be editing a mw sourcefile. I am once again
free to work on multiple open-source projects without heaping
disapprobation and calumny on myself and others.
With love,
Adam
=====
" surprise! ascii 9 is back from the dead ... what, are we writing
Makefiles??
autocmd BufNewFile,BufRead */mediawiki-*/** set tabstop=4 noexpandtab
In the OAuth user stories it was suggested that we might want to support
OAuth "Implicit Grant".
-- Explanation of "Implicit Grant" --
In OAuth 2 the "Implicit Grant" is one where you send the user to the
Authorization endpoint. The user allows your application access. And then
sends the user back to the client with the Access token directly inside
the #fragment of the page. Instead of sending the user back with an
Authorization code in the query that lets the client request an Access
token.
This grant flow is useful for pure-JS applications with no server
component. For example browser extensions and more importantly
pure-JavaScript applications that don't want to interact with the server
they're on at all. eg: They may be served 100% statically with no
scripting on the server end. And they may support offline mode so the
server the application sits on doesn't even need to be online, while
thousands of people can be using the app.
((And I have a feeling this is the flow that all B2G based mobile phone
applications will end up using))
-- /Explanation --
My thought on this topic here is that for such applications in addition to
OAuth we're also going to have to consider implementing CORS in MediaWiki.
-- Rationale; Skip for TL;DR --
pure-JS applications naturally will want to use XHR for making API
requests. However the sameorigin policy will prevent them from accessing
the api.
Technically JSONP exists. But OAuth access tokens going over <script>s is
a horrid idea. You can't use 'mac' type access tokens over JSONP. JSONP is
insecure. And most importantly JSONP can't do POST. Which means that an
OAuth client using JSONP can't use the write api, which is practically the
whole reason for using OAuth.
Using a server to forward requests is completely unnecessary and adds a
hardware burden on the developer that does not need to exist. It also
makes the implicit grant pointless since you could just use the
Authorization Code Grant from the server.
-- /Rationale --
So naturally this means that along with OAuth we're going to have to
support CORS.
I have some ideas on how we should deal with CORS support:
- We'll always permit CORS requests, even without an OAuth authorization.
- Just like with JSONP all CORS requests lose session data and become
anonymous requests. (TBH, the best way to implement this would probably
actually involve unset() on all $_COOKIE and $_SESSION data so extensions
can't accidentally expose sensitive data)
- With the exception that a CORS request can contain an OAuth access token
and act as a user (potentially a different user than the one logged in at
that)
- CORS requests will be restricted to the API. Since there are some parts
of the site that could be problematic when accessed by the
- CORS requests will not have access to the write api. (ie: It will be
disabled without OAuth + an edit, etc... rights grant) This is different
than normal XHR requests to prevent random websites from being able to
make anonymous edits simply by having some random victim browse to their
website.
This will allow CORS + OAuth "Implicit Grant" to be used by client based
web applications. It will also allow a client based web application to
safely make a meta=siteinfo request before going in for an OAuth
authorization. Actually it'll just plain make it possible to ditch JSONP
for everything we were using it for before. Something I think we DO want
to encourage because of the security implications that JSONP has.
The only issue a client application may have right now with that CORS
setup might be discovery. We don't allow CORS requests for random pages on
the wiki. So the client won't be able to let the user input the url of a
random wiki and have the client do a RSD discovery on the wiki to find the
API url and start the oauth flow.
I suppose we could write a 3rd party service that'll do discovery and
allow random client-side web applications do discovery of random MediaWiki
installations.
((By the way. When we implement CORS I want an early peak at it. I can
already think of one security hole a mistake in the implementation could
open up))
((Actually I just came up with a second one right now. We need to make
sure that the edit tokens for OAuth requests are different than the actual
edit tokens. Otherwise they could be abused to trick the user's browser
into making an edit with the full authority of the user bypassing OAuth
restrictions.))
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Due to various requestes popping out on IRC I visting sometimes
some random extensions to MediaWiki. Today's pick was
https://www.mediawiki.org/wiki/Extension:WikiForum
The infobox says it is available on Git - I remember
the old version was giving pointers to SVN and Git.
Git links there give 404, as the extensions still
rests in
http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/WikiForum/
Now that ExtensionDistributor works nice with git,
shouldn't we have {{WikimediaGit}} and {{WikimediaSVN}} templates,
or let the {{WikimediaDownload}} point to SVN where necessary (older
releases or something?)
I don't fully follow what's happening there and what's the plan...
anyone?
//Saper
I've been reading over various OAuth related specs and resources.
Some interesting things I learned while reading up:
== Clients cannot be trusted with security ==
As far as SSL/TLS goes, this doesn't provide OAuth with as much security
as one might think.
The whole "SSL is broken" factor aside (You know, all the flaws with
CA's and whatnot; https://www.youtube.com/watch?v=Z7Wl2FW2TcA if you
fell like watching something you might not have).
It looks like app's cannot be trusted with something as /simple/ as
actually verifying that they are talking with the right server (You
know, that MITM protection that was the whole point of OAuth using HTTPS)
3 point on that:
- It seems that the CA root trust setup is not setup by default on
various servers and isn't necessarily very easy to setup
- In php's default settings for ssl:// and https:// the default for
verify_peer "False". In other words, by default https:// connections
made using PHP's native code is no more secure than http://
- App developers often run into cURL throwing an error saying that a ssl
certificate is invalid (because of the first point, no root certs setup
on the machine). When this happens, the reaction of many app developers
is to set verify_peer = False. In fact, there are people that go around
and RECOMMEND this when people ask for help.
If you want some more reading on this topic, these two articles are good:
http://blog.astrumfutura.com/2010/10/do-cryptographic-signatures-beat-ssltl…http://hueniverse.com/2010/09/oauth-bearer-tokens-are-a-terrible-idea/
Considering this point on security and the fact that we're not using a
proprietary API and discoverability is eventually going to be a big
thing for us I think that when we implement OAuth we should make use of
signatures mandatory for clients.
We can still allow bearer tokens to be used during development. But
impose extreme rate limits on them to prevent abuse in production (ie:
rate limits more restrictive than api anons currently get).
== We can't always guarantee OAuth authorizations really come from a
client ==
OAuth has the notion of a client_id and a client_secret. There are two
types of clients, "confidential" ones like those on hosted servers, and
"public" ones like client-only web apps, desktop, and mobile apps.
public clients don't get a client_secret because it's impossible to keep
a secret a secret when you hand the entire app over to every user that
wants it. Hence when it comes to public clients you cannot guarantee
that when a user authorized an app the app was actually the app it says
it is.
It means for example. That en.wp could suddenly see bot spam that says
it was made by the anti-vandal tool "Huggle". Because Huggle would be a
public client and the client_id would be public so any random client
could say it's Huggle when a user authorizes it.
This means a few things for us:
- We should make the difference between an edit made by a confidential
client and one made by a public client visible in the UI so editors know
the difference.
- We shouldn't delude ourselves into thinking we can mass-revert based
on client_id when said client is a public client. Instead we should
forget that whole idea and allow admins to see individual authorizations
given by users to public clients and let admins select whole swaths of
them and mass-revert them all at once.
- Under that thought. Since we're going to go to the trouble of building
tools to mass-revert. Perhaps we should take that extra step and make it
a general mass-revert tool. The filtering capability isn't as hard as
the revert handling. Instead of just client_id and authorization we
could let admins mass-revert a selection of users.
== OAuth is a pretty loose protocol ==
OAuth actually leaves a lot undefined:
- The actual verification of a user is completely outside of the scope
of the spec. So it doesn't care whether you make the user login normally
or use some sort of web based device flow within the login system itself
to let web based mobile applications get OAuth grants using the normal
Authorization Code Grant flow but the user themselves get to feel like
they are using a device flow.
- Getting a token and using it are defined separately. Enough that you
could go out-of-spec and write a different method of getting a token. In
fact instead of making you tweak sections of the OAuth protocol as you
would in OAuth 1.0 the OAuth 2 spec has a section on "Extension Grants"
that allow you to specify new methods of getting auth_tokens which you
can use to create a new flow.
- While some application flows are defined by the spec you still have
room to implement new types of flows if you have a use-case for it.
- Discoverability is completely out of scope of the OAuth spec. You have
room to develop your own pattern of discoverability. (And with
signatures you might even be able to come up with a way to make wikis
run over http:// secure enough to use OAuth)
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]