The future of action=ajax

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

The future of action=ajax

Bryan Tong Minh
Hi,


As you may know there are currently two entry points in MediaWiki for
javascript that wants to perform certain actions, action=ajax and
api.php. Only the following features still use action=ajax: ajax
watch, upload license preview and upload warnings check. I don't
really see much point for two entry points where one would suffice.
These could all be readily migrated to the API. However, this would
mean that they will become unavailable if the API is disabled. Would
that considered to be a problem?


Bryan

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The future of action=ajax

Daniel Kinzler
Bryan Tong Minh schrieb:
> Hi,
>
>
> As you may know there are currently two entry points in MediaWiki for
> javascript that wants to perform certain actions, action=ajax and
> api.php. Only the following features still use action=ajax: ajax
> watch, upload license preview and upload warnings check.

Don't forget extensions, like categorytree

-- daniel

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The future of action=ajax

Daniel Kinzler
In reply to this post by Bryan Tong Minh
Bryan Tong Minh schrieb:
> Hi,
>
>
> As you may know there are currently two entry points in MediaWiki for
> javascript that wants to perform certain actions, action=ajax and
> api.php.

Oh, also: action=ajax supports http cache control. can this be done with the api
yet?

-- daniel

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The future of action=ajax

Roan Kattouw-2
2010/1/9 Daniel Kinzler <[hidden email]>:
> Oh, also: action=ajax supports http cache control. can this be done with the api
> yet?
>
Yes, with the maxage and smaxage parameters. AFAIK those are currently
broken on Wikimedia, however, because Squid overrides the caching
headers set by the API.

Roan Kattouw (Catrope)

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Controlling of article / parser cache in extension code

Dmitriy Sintsov
Hi!
I have an extension, which submits and renders polls defined with parser
tag hooks. To have the article view properly re-generate dymanical
content of tag, the typical approach is to use $parser->disableCache()
in hook's function. However, in my case, the dynamically generated
content is changed only when the poll was successfully submitted. When a
user just views the page and makes no vote, the content doesn't change,
thus, should be cached to improve the performance.

When I comment out $parser->disableCache() line, the content of page is
not being updated, until one purges the page manually, which is very
unhandy. So I used to have this call unconditionally, which is
inefficient.

But, I am (with my limited knowledge of core) cannot find out, which
calls should I make to invalidate parser cache and article cache in the
extension's code on demand (conditionally). In the point of code, where
the user had successfully POSTed voting data and the results of vote
were stored in the DB, I try to execute the following methods:

$wgArticle->doPurge();
$wgTitle->invalidateCache();

then perform a a 302 redirect to show the same title with updated poll
results.

However, when I comment out the $parser->disableCache() line, tag
function output content is not being displayed at all. Like if there
were no tags at the page.

What would you suggest? My only idea to implement GET action which will
conditionally purge the page. I don't like such approach.

Thanks,
Dmitriy

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The future of action=ajax

Bryan Tong Minh
In reply to this post by Daniel Kinzler
On Sat, Jan 9, 2010 at 5:03 PM, Daniel Kinzler <[hidden email]> wrote:

> Bryan Tong Minh schrieb:
>> Hi,
>>
>>
>> As you may know there are currently two entry points in MediaWiki for
>> javascript that wants to perform certain actions, action=ajax and
>> api.php. Only the following features still use action=ajax: ajax
>> watch, upload license preview and upload warnings check.
>
> Don't forget extensions, like categorytree
>
I was not yet planning to kill action=ajax itself, just all functions
that use. There is really no reason to break backwards compatibility
here.


Bryan

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The future of action=ajax

Aryeh Gregor
In reply to this post by Bryan Tong Minh
On Sat, Jan 9, 2010 at 7:54 AM, Bryan Tong Minh
<[hidden email]> wrote:
> These could all be readily migrated to the API. However, this would
> mean that they will become unavailable if the API is disabled. Would
> that considered to be a problem?

No.  At this point we should remove $wgEnableAPI and set it to true
unconditionally.  Other things already randomly depend on it, like
watchlist RSS feeds.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The future of action=ajax

Angela-5
On Sun, Jan 10, 2010 at 3:15 PM, Aryeh Gregor
<[hidden email]> wrote:
> No.  At this point we should remove $wgEnableAPI and set it to true
> unconditionally.  Other things already randomly depend on it, like
> watchlist RSS feeds.

Enabling it has caused data to be leaked from private wikis in the
past. Has that been fixed?

Angela

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The future of action=ajax

liangent
It seems to be fixed. I got the following message when I tried to get
data from a private wiki via API.

<error code="readapidenied" info="You need read permission to use this
module" xml:space="preserve">


On 1/10/10, Angela <[hidden email]> wrote:

> On Sun, Jan 10, 2010 at 3:15 PM, Aryeh Gregor
> <[hidden email]> wrote:
>> No.  At this point we should remove $wgEnableAPI and set it to true
>> unconditionally.  Other things already randomly depend on it, like
>> watchlist RSS feeds.
>
> Enabling it has caused data to be leaked from private wikis in the
> past. Has that been fixed?
>
> Angela
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The future of action=ajax

Aryeh Gregor
In reply to this post by Angela-5
On Sun, Jan 10, 2010 at 3:52 AM, Angela <[hidden email]> wrote:
> Enabling it has caused data to be leaked from private wikis in the
> past. Has that been fixed?

I'd sure hope so.  If not, I'm pretty sure the right thing to do is
fix it, not just disable the feature.  We could leave the option but
say it's unsupported, but either way, it doesn't make much sense to me
at this point to care what happens to people who disable the API.
It's no longer just for bots.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The future of action=ajax

Roan Kattouw-2
In reply to this post by Angela-5
2010/1/10 Angela <[hidden email]>:
> On Sun, Jan 10, 2010 at 3:15 PM, Aryeh Gregor
> <[hidden email]> wrote:
>> No.  At this point we should remove $wgEnableAPI and set it to true
>> unconditionally.  Other things already randomly depend on it, like
>> watchlist RSS feeds.
>
> Enabling it has caused data to be leaked from private wikis in the
> past. Has that been fixed?
>
Actually, the API is now overly restrictive on private wikis,
disallowing all actions except login from users without read rights.
This means they can't get certain data that they could get through the
UI (like the content of whitelisted pages such as the main page, the
/name/ of the main page, the wiki's name and content language, etc.).
For most users this is annoying and should be fixed, but for operators
of private wikis it's probably a comforting thought that, for now,
even the most innocent requests to do anything but log in will be
denied to users without read rights.

Roan Kattouw (Catrope)

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Controlling of article / parser cache in extension code

Dmitriy Sintsov
In reply to this post by Dmitriy Sintsov
* Dmitriy Sintsov <[hidden email]> [Sat, 09 Jan 2010 23:12:30
+0300]:
I've managed to do this by clearing "internal" memc key for the selected
article and user object in ParserCache. Also, by setting a cookie before
sending the redirect headers, so the next GET would know the data were
posted. Still unsure how well would it work with every version / setup
of MediaWiki out there. Let's hope the future changes of core won't
interfere. Once, a long time ago, I've had a horrible issue with my
security extension, when new "optimisation of userCan for readonly
wikis" was introduced, I think in 1.12..
Dmitriy

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l