Re: [Wikitech-l] SOLVED Re: VisualEditor in 1.28 - fails after upgrade from 1.27

2016-12-20 Thread Daniel Barrett 
On 2016-12-20 06:22, Daniel Barrett wrote:
>>> My goal is to remove some special pages for anonymous users but permit
>>> logged-in users to see them.
>>> Is there a better way to check for a logged-in user at this hook point?
>>> Or a better way to remove special pages for anonymous users?

Bartosz Dziewoński  replied:
>> Yes, the list of special pages can't depend on anything related to the
>> current user.
>>
>> Instead, you should check whether the user is logged in when displaying
>> the special page. You can just call `$this->requireLogin();` at the
>> beginning of the special page's execute() function...

Brad Jorsch (Anomie) added:
>And to hide a special page on Special:SpecialPages from users who can't use
>it, have the page's userCanExecute() return false when appropriate and have
>isRestricted() return true. If the check is based on having one user right,
>this can be easily done by passing the user right as the $restriction
>parameter to SpecialPage::__construct().

Thanks! Since I am trying to hide *all* special pages (except login, logout, 
and search),
from anonymous users, not just custom special pages that I wrote, these 
solutions
won't quite work. I'll try using the hook "SpecialPageBeforeExecute" to check
if the user is logged in, then blocking the execution if not. Then maybe a 
separate hook
to prevent special pages from showing up in the search box auto-suggestions, 
maybe
"ApiOpenSearchSuggest"?

As an additional note, even after removing the problematic code, VisualEditor is
still not loading. I guess the errors I saw were red herrings. Now there are no 
errors
at all showing up when VE fails. :-(  I'll do some more debugging and follow up.

DanB
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] SOLVED Re: VisualEditor in 1.28 - fails after upgrade from 1.27

2016-12-20 Thread Brad Jorsch (Anomie) 
On Tue, Dec 20, 2016 at 2:00 AM, Bartosz Dziewoński 
wrote:

> On 2016-12-20 06:22, Daniel Barrett wrote:
>
>> The real issue is that a custom callback for the hook
>> "SpecialPages_initList" is invoking RequestContext::getMain()->get
>> User()->isLoggedIn().
>>
>> Apparently that doesn't work.
>>
>> I'll take a guess that SpecialPages_initList runs too early for this
>> check to succeed?
>>
>>
>> My goal is to remove some special pages for anonymous users but permit
>> logged-in users to see them.
>> Is there a better way to check for a logged-in user at this hook point?
>> Or a better way to remove
>> special pages for anonymous users?
>>
>
> Yes, the list of special pages can't depend on anything related to the
> current user.
>
> Instead, you should check whether the user is logged in when displaying
> the special page. You can just call `$this->requireLogin();` at the
> beginning of the special page's execute() function – this will check
> whether the user is logged in, and if not, display an error message and
> abort execution. You can optionally pass a custom error message. See e.g.
> /includes/specials/SpecialWatchlist.php in MediaWiki for an example.
>

And to hide a special page on Special:SpecialPages from users who can't use
it, have the page's userCanExecute() return false when appropriate and have
isRestricted() return true. If the check is based on having one user right,
this can be easily done by passing the user right as the $restriction
parameter to SpecialPage::__construct().


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] SOLVED Re: VisualEditor in 1.28 - fails after upgrade from 1.27

2016-12-19 Thread Bartosz Dziewoński 

On 2016-12-20 06:22, Daniel Barrett wrote:

The real issue is that a custom callback for the hook "SpecialPages_initList" is 
invoking RequestContext::getMain()->getUser()->isLoggedIn().

Apparently that doesn't work.

I'll take a guess that SpecialPages_initList runs too early for this check to 
succeed?


My goal is to remove some special pages for anonymous users but permit 
logged-in users to see them.
Is there a better way to check for a logged-in user at this hook point? Or a 
better way to remove
special pages for anonymous users?


Yes, the list of special pages can't depend on anything related to the 
current user.


Instead, you should check whether the user is logged in when displaying 
the special page. You can just call `$this->requireLogin();` at the 
beginning of the special page's execute() function – this will check 
whether the user is logged in, and if not, display an error message and 
abort execution. You can optionally pass a custom error message. See 
e.g. /includes/specials/SpecialWatchlist.php in MediaWiki for an example.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] SOLVED Re: VisualEditor in 1.28 - fails after upgrade from 1.27

2016-12-19 Thread Daniel Barrett 
OK, I have traced the issue, and I'm embarrassed to say, it's in a custom 
extension.

(I removed the extension yesterday and the error kept happening, so I figured 
the extension

was harmless... but I'll bet I was fooled by browser caching.)

Apologies if my incorrect information wasted anyone's time.


The real issue is that a custom callback for the hook "SpecialPages_initList" 
is invoking RequestContext::getMain()->getUser()->isLoggedIn().

Apparently that doesn't work.

I'll take a guess that SpecialPages_initList runs too early for this check to 
succeed?


My goal is to remove some special pages for anonymous users but permit 
logged-in users to see them.

Is there a better way to check for a logged-in user at this hook point? Or a 
better way to remove

special pages for anonymous users?


Thank you very much for any advice,

DanB



From: Daniel Barrett
Sent: Monday, December 19, 2016 8:21 PM
To: Wikimedia developers
Subject: Re: [Wikitech-l] VisualEditor in 1.28 - fails after upgrade from 1.27


> Ok, that's a start. Can you get the rest of the stack trace for the
> exception so we can figure out how that's getting called?


Sure. How do I get a full stack dump when the error appears only in the Chrome 
developer console?

   BadMethodCallException from line 845 of 
<...>/w/includes/session/SessionManager.php:
   Sessions are disabled for this entry point

I've already enabled $wgShowExceptionDetails (which caused slightly more detail 
to appear,
but no stack dump) and set every other debugging flag in sight on 
https://www.mediawiki.org/wiki/Manual:How_to_debug#PHP_errors in 
LocalSettings.php and in index.php.
The only output I get is the above line in the Chrome developer console.
The error does not appear in the associated Apache error log file.

DanB


From: Wikitech-l  on behalf of Alex 
Monk 
Sent: Monday, December 19, 2016 9:38 AM
To: Wikimedia developers
Subject: Re: [Wikitech-l] VisualEditor in 1.28 - fails after upgrade from 1.27

I feel like that sessions error was something we fixed months ago but can't
find details right now. Certainly not the first time I've seen it...

On 19 Dec 2016 3:31 pm, "Brad Jorsch (Anomie)" 
wrote:

> On Mon, Dec 19, 2016 at 8:20 AM, Daniel Barrett  wrote:
>
> > Here you go:
> >
> >
> > BadMethodCallException from line 845 of <...>/w/includes/session/
> SessionManager.php:
> > Sessions are disabled for this entry point
> >
> >
> > load.php?debug=false=en=startup=scripts=vector:4
> > [43d736c07dd76d73cf26db20] /w/load.php?debug=false=
> > en=startup=scripts=vector BadMethodCallException
> from
> > line 845 of <...>/w/includes/session/SessionManager.php: Sessions are
> > disabled for this entry point
> >
>

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l