Announcements and discussion about the MediaWiki API ()

headers Bogdan Pop | 2 Aug 2007 09:50

_______________________________________________
Mediawiki-api mailing list
Mediawiki-api@...
http://lists.wikimedia.org/mailman/listinfo/mediawiki-api

It seems there are still some issues on the server-side searching. My
guess it will start working fine the moment the rest of the core code
is updated. For now, the the only working change is addition of the
long awaited edit tokens.  prop=info & intoken=edit|move...

--Yuri

On 8/2/07, Bogdan Pop <melccodobelc@...> wrote:
>
> Hey.
> Now the api works (I do not get the error xml), but I get no results, no
> matter what I search:
> http://en.wikipedia.org/w/api.php?action=query&list=search&srsearch=wikipedia&srlimit=10
>
> For all 3 examples under the api search doc, I get no results:
> http://en.wikipedia.org/w/api.php?action=query&list=search&srsearch=meaning
> http://en.wikipedia.org/w/api.php?action=query&list=search&srwhat=text&srsearch=meaning
> http://en.wikipedia.org/w/api.php?action=query&generator=search&gsrsearch=meaning∝=info
> For the last one, I get the empty xml: <api/>
> What's wrong? Many thanks,
> Bogdan
>
>
> ----- Original Message ----
> From: Yuri Astrakhan <yuriastrakhan@...>
> To: MediaWiki API announcements & discussion
> <mediawiki-api@...>
> Sent: Tuesday, July 31, 2007 7:03:04 PM
> Subject: Re: [Mediawiki-api] New API features and changes
>
> All changes have been checked into the svn, but the servers have not
> been updated yet. Should happen soon, keep checking the api.php page.
>
> >
> > I get:
> > <error code="unknown_list" info="Unrecognised value for parameter 'list'">
> >
> > Thanks,
> > Bogdan
> >
> >
> > ----- Original Message ----
> > From: Yuri Astrakhan <yuriastrakhan@...>
> > To: MediaWiki API announcements & discussion
> > <mediawiki-api@...>
> > Sent: Monday, July 30, 2007 11:38:56 AM
> > Subject: [Mediawiki-api] New API features and changes
> >
> >
> > New Features:
> > * list=search:  Full text search has been added - both titles and
> > content are now search-able.
> > * list=allusers: Added groups - can be both filtered by a specific
> > group, and shown the groups the users belong to. (bug 10684 by
> > VasilievVV)
> >
> > Breaking change:
> > * prop=revisions: I removed the redundant pageid= attribute in the
> > <rev> tag - pageid is already given as part of the parent <page>
> > element. (Thx Platonides)
> >
> > Your help is still needed to improve documentation at
> > http://www.mediawiki.org/wiki/API - each function and
> > parameter needs
> > better documentation, with many simple examples. There is a template
> > to help with the presentation.
> >
> > As usual, if you notice any bugs -- http://bugzilla.wikimedia.org
> > Awaiting server sync for changes to go live.
> >
> > --Yurik
> >
> > _______________________________________________
> > Mediawiki-api mailing list
> > Mediawiki-api@...
> > http://lists.wikimedia.org/mailman/listinfo/mediawiki-api
> >
> >
> >  ________________________________
> > Yahoo! oneSearch: Finally, mobile search that gives answers, not web
> links.
> > _______________________________________________
> > Mediawiki-api mailing list
> > Mediawiki-api@...
> > http://lists.wikimedia.org/mailman/listinfo/mediawiki-api
> >
> >
>
> _______________________________________________
> Mediawiki-api mailing list
> Mediawiki-api@...
> http://lists.wikimedia.org/mailman/listinfo/mediawiki-api
>
>
>  ________________________________
> Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on,
> when.
> _______________________________________________
> Mediawiki-api mailing list
> Mediawiki-api@...
> http://lists.wikimedia.org/mailman/listinfo/mediawiki-api
>
>

It was great to meat many of you during the Wikimania conference in
Taipei. Thank you for all the ideas and suggestions.

Breaking change:

I have changed the prop=imageinfo a bit to return size values as
integers in json format.
More importantly, in order to simplify imageinfo format, the
repository name is now an attribute of the page element, not the
imageinfo element.

Examples:

Missing image:
    <pages>
      <page ns="6" title="Image:someNonExistingImage.jpg" missing=""
imagerepository="" />
    </pages>

Image exists:
      <page pageid="25046" ns="6" title="Image:Test.jpg"
imagerepository="local">
        <imageinfo>
          <ii size="105542" width="800" height="600" />
          <ii size="28521" width="800" height="600" />
        </imageinfo>
      </page>

Image exists -- json:
		"pages": {
			"25046": {
				"pageid": 25046,
				"ns": 6,
				"title": "Image:Test.jpg",
				"imagerepository": "local",
				"imageinfo": [
					{
						"size": 105542,
						"width": 800,
						"height": 600
					},
					{
						"size": 28521,
						"width": 800,
						"height": 600
					}
				]
			}
		}

New:
* Added rvprop=size to prop=revisions. Can get the size of all the
revisions. The size will not be shown if it is NULL in the database.

* (Experimental) list=allpages now allows to filter by article min/max
size and protection status (thanks to [[en:user:madman]] for the
idea).  The database performance of this addition might be so severe
that I might have to remove or restrict it.

Breaking change:
* list=exturlusage XML element's tag is now 'eu' instead of 'p' to be
more consistent with the other results.

I would like some feedback on the issue of how to allow API users to
prove who they are without using a cookie (some clients simply do not
support them), but instead pass all relevant information in the
URL/POST.

The login api module returns userID, userName, and userToken - all
necessary parts of a cookie. The client should be able to pass those
values in the URL, which should override the browser cookie (or lack
thereof), and instead resume the session specified.

The $_SESSION object gets initialized based on the cookie before the
php code starts. In order to resume the session, I could set
$_SESSION['wsUserID'], $_SESSION['wsUserName'], $_SESSION['wsToken']
to the URL values, and set $wgUser = User::newFromSession() before any
other operations.

Does this introduce any security risks? Is there another way to solve this?

Thanks!

Hi Yuri,

In my humble opinion, passing session information in a URL is a bad
idea. This could lead to social engineering attacks "paste your
address to me" where people can then get the Session ID and thus
manipulate the user's login. This is why cookies are the default.

POST would probably work okay, though. But then, you'd have to use
buttons to go anywhere on your site, and the code just starts becoming
unmaintainable.

I would highly suggest that you just stick to the (default?) Cookie
configuration...

In terms of external security risks, aside from the social engineering
factor, if all the pages are viewed over HTTPS you should be fine.
There is a bit of a problem when you start mixing HTTP and HTTPS using
the same session, since somebody snooping on the connection could grab
the Session ID via HTTP and use it to do nefarious things. But this
applies to cookies as well.

Just make sure that you either use separate Session IDs for HTTP and
HTTPS, and that you specify http:// and https:// respectively in your
cookies, to ensure that session cookies tied to authenticated users
won't be sent in-the-clear.

I hope this helps you. If you have any other questions, feel free to
mail me off-list.

Regards,

Jonathan Yu

On 8/9/07, Yuri Astrakhan <yuriastrakhan@...> wrote:
> I would like some feedback on the issue of how to allow API users to
> prove who they are without using a cookie (some clients simply do not
> support them), but instead pass all relevant information in the
> URL/POST.
>
> The login api module returns userID, userName, and userToken - all
> necessary parts of a cookie. The client should be able to pass those
> values in the URL, which should override the browser cookie (or lack
> thereof), and instead resume the session specified.
>
> The $_SESSION object gets initialized based on the cookie before the
> php code starts. In order to resume the session, I could set
> $_SESSION['wsUserID'], $_SESSION['wsUserName'], $_SESSION['wsToken']
> to the URL values, and set $wgUser = User::newFromSession() before any
> other operations.
>
> Does this introduce any security risks? Is there another way to solve this?
>
> Thanks!
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@...
> http://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

_______________________________________________
Mediawiki-api mailing list
Mediawiki-api@...
http://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Yuri Astrakhan wrote:
> I would like some feedback on the issue of how to allow API users to
> prove who they are without using a cookie (some clients simply do not
> support them), but instead pass all relevant information in the
> URL/POST.
> 
> The login api module returns userID, userName, and userToken - all
> necessary parts of a cookie. The client should be able to pass those
> values in the URL, which should override the browser cookie (or lack
> thereof), and instead resume the session specified.
> 
> The $_SESSION object gets initialized based on the cookie before the
> php code starts. In order to resume the session, I could set
> $_SESSION['wsUserID'], $_SESSION['wsUserName'], $_SESSION['wsToken']
> to the URL values, and set $wgUser = User::newFromSession() before any
> other operations.
> 
> Does this introduce any security risks? Is there another way to solve this?
> 
> Thanks!

This makes sense to me.  Passing the ?PHPSESSID= query string should be 
a perfectly acceptable alternative to cookies; that's for what it was 
made.  As for Jonathan mentioned, though: You might want to include the 
$_SERVER['REMOTE_ADDR'] in $_SESSION and then check it when 
authenticating the user.  Bots' IP addresses should not be changing in 
the middle of a run, and it could prevent replay attacks like those he 
describes.

-madman bum and angel

Here is a very minor but annoying bug:

http://en.wikipedia.org/w/api.php?action=query&titles=-100&prop=info&redirects=redirects&format=jsonfm

Note that in the response, the title -100 is not quoted in the redirects 
value --

"redirects": [
  {
    "from": -100,
    "to": "100 BC"
  }
],

This apparently happens only in JSON, and only for redirects; when I run the 
same query without the 'format' parameter, the title is quoted. When I run a 
query without the 'redirects' parameter, the title is quoted, even in JSON.

Interpreting the page title as an int instead of a string drives my client 
program crazy!  :)

Russ Blau

> In my humble opinion, passing session information in a URL is a bad
> idea. This could lead to social engineering attacks "paste your
> address to me" where people can then get the Session ID and thus
> manipulate the user's login. This is why cookies are the default.
In general, you are right. However, I doubt if this api use will happen
often: the api is an advanced *programming* interface, and not meant for
general client use ;). I assume Yuri wants to introduce it because many
simple (and even many more advanced) http client libraries do not support
cookies.

> POST would probably work okay, though. But then, you'd have to use
> buttons to go anywhere on your site, and the code just starts becoming
> unmaintainable.
Well, again, no. For api use this could be used, as the client can just
add post data. It's not necessary to browse the entire wiki using this
system, only api.php has to accept it :)

--valhallasw

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

22	May 2013
41	April 2013
52	March 2013
34	February 2013
33	January 2013
72	December 2012
43	November 2012
8	October 2012
12	September 2012
26	August 2012
8	July 2012
50	June 2012
37	May 2012
16	April 2012
15	March 2012
28	February 2012
34	January 2012
24	December 2011
11	November 2011
41	October 2011
36	September 2011
30	August 2011
15	July 2011
19	June 2011
31	May 2011
20	April 2011
47	March 2011
58	February 2011
51	January 2011
27	December 2010
51	November 2010
54	October 2010
32	September 2010
16	August 2010
32	July 2010
75	June 2010
25	May 2010
72	April 2010
79	March 2010
103	February 2010
16	January 2010
25	December 2009
20	November 2009
31	October 2009
78	September 2009
56	August 2009
58	July 2009
64	June 2009
79	May 2009
20	April 2009
43	March 2009
90	February 2009
78	January 2009
37	December 2008
13	November 2008
67	October 2008
34	September 2008
59	August 2008
41	July 2008
22	June 2008
41	May 2008
82	April 2008
60	March 2008
36	February 2008
72	January 2008
31	December 2007
96	November 2007
55	October 2007
11	September 2007
36	August 2007
43	July 2007

Re: New API features and changes

Re: New API features and changes

Wikimania is over, time to change ImageInfo

Changes and new features

Designing coockie-less login for API

Re: Designing coockie-less login for API

Re: New API features and changes

Re: Designing coockie-less login for API

Bug report

Re: [Wikitech-l] Designing coockie-less login for API