Bogdan Pop | 2 Aug 09:50 2007
Picon

Re: New API features and changes

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& amp;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∝=infoFor the last one, I get the empty xml: <api/>
What's wrong? Many thanks,
Bogdan


----- Original Messa ge ----
From: Yuri Astrakhan <yuriastrakhan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: MediaWiki API announcements & discussion <mediawiki-api-RusutVdil2icGmH+5r0DM0B+6BGkLq7r@public.gmane.org>
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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> To: MediaWiki API announcements & discussion
> <mediawiki-api-RusutVdil2icGmH+5r0DM0B+6BGkLq7r@public.gmane.org>
> Sent: Monday, July 30, 2007 11:38:5 6 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-RusutVdil2icGmH+5r0DM0B+6BGkLq7r@public.gmane.org
> 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-RusutVdil2icGmH+5r0DM0B+6BGkLq7r@public.gmane.org
> http://lists.wikimedia.org/mailman/listinfo/mediawiki-api
>
>
_______________________________________________
Mediawiki-api mailing list
Mediawiki-api-RusutVdil2icGmH+5r0DM0B+6BGkLq7r@public.gmane.org
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
Yuri Astrakhan | 2 Aug 16:32 2007
Picon

Re: New API features and changes

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
>
>
Yuri Astrakhan | 7 Aug 06:57 2007
Picon

Wikimania is over, time to change ImageInfo

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
					}
				]
			}
		}
Yuri Astrakhan | 9 Aug 12:46 2007
Picon

Changes and new features

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.
Yuri Astrakhan | 9 Aug 13:08 2007
Picon

Designing coockie-less login for API

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!
Jonathan Yu | 9 Aug 17:19 2007
Picon

Re: Designing coockie-less login for API

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
>
Bogdan Pop | 9 Aug 18:40 2007
Picon

Re: New API features and changes

Hi Yuri!
The search still returns empty xml's, how much long do you think it will take before is it usable ?
Thanks,
Bogdan
----- Original Message ----
From: Yuri Astrakhan <yuriastrakhan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: MediaWiki API announcements & discussion <mediawiki-api-RusutVdil2icGmH+5r0DM0B+6BGkLq7r@public.gmane.org>
Sent: Thursday, August 2, 2007 5:32:39 PM
Subject: Re: [Mediawiki-api] New API features and changes

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-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> 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
&g t; 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> To: MediaWiki API announcements & discussion
> <mediawiki-api-RusutVdil2icGmH+5r0DM0B+6BGkLq7r@public.gmane.org>
> 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > To: MediaWiki API announcements & discussion
> > <mediawiki-api-RusutVdil2icGmH+5r0DM0B+6BGkLq7r@public.gmane.org>
> > 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-RusutVdil2icGmH+5r0DM0B+6BGkLq7r@public.gmane.org
> > 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-RusutVdil2icGmH+5r0DM0B+6BGkLq7r@public.gmane.org
> > http://lists.wikimedia.org/mailman/listinfo/mediawiki-api
> >
&g t; >
>
> _______________________________________________
> Mediawiki-api mailing list
> Mediawiki-api-RusutVdil2icGmH+5r0DM0B+6BGkLq7r@public.gmane.org
> 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-RusutVdil2icGmH+5r0DM0B+6BGkLq7r@public.gmane.org
> http://lists.wikimedia.org/mailman/listinfo/mediawiki-api
>
>

_______________________________________________
Mediawiki-api mailing list
Mediawiki-api-RusutVdil2icGmH+5r0DM0B+6BGkLq7r@public.gmane.org
http://lists.wikimedia.org/mailman/listinfo/mediawiki-api


Need a vacation? Get great deals to amazing places on Yahoo! Travel.
_______________________________________________
Mediawiki-api mailing list
Mediawiki-api@...
http://lists.wikimedia.org/mailman/listinfo/mediawiki-api
madman bum and angel | 9 Aug 18:03 2007

Re: Designing coockie-less login for 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
Russell Blau | 9 Aug 22:47 2007

Bug report

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
Merlijn van Deen | 10 Aug 10:45 2007
Picon

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

> 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

Gmane