この予定はキャンセルされ、カレンダーから削除されました。
タイトル: MediaWiki-l Digest, Vol 158, Issue 11
Send MediaWiki-l mailing list submissions to
mediawiki-l(a)lists.wikimedia.orgTo subscribe or unsubscribe via the World
Wide Web, visit https://lists.wikimedia.org/mailman/listinfo/mediawiki-lor,
via email, send a message with subject or body 'help' to
mediawiki-l-request(a)lists.wikimedia.orgYou can reach the person managing
the list at mediawiki-l-owner(a)lists.wikimedia.orgWhen replying, please edit
your Subject line so it is more specificthan "Re: Contents of MediaWiki-l
digest..."Today's Topics: 1. Re: MediaWiki Timezone
(John)_______________________________________________MediaWiki-l mailing
listMediaWiki-l@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/mediawiki-l
日時: 毎日 午後1時～午後2時 GMT (夏時間なし)
カレンダー: mediawiki-l(a)lists.wikimedia.org
参加者:
* 優希船越- 主催者
* mediawiki-l(a)lists.wikimedia.org
* Wikipedia
Google カレンダーからの招待状: https://www.google.com/calendar/
予定の参加者になっているため、本メールを mediawiki-l(a)lists.wikimedia.org に
お送りしています。
今後この予定の更新を受け取らないようにするには、この予定を拒否してください。
あるいは、https://www.google.com/calendar/ で Google カレンダーのアカウント
を登録すると、カレンダー全体の通知機能を設定できます。
この招待状を転送すると、他の受信者によってあなたの出欠状況が変更される可能性
があります。詳細については
https://support.google.com/calendar/answer/37135#forwarding をご覧ください
Scott,
I double checked the Short URL manual page [0], because you mentioned that
you planned to switch to short URLs due to this issue. We do not use short
URLs, so there must be something else going on. What struck me on the
manual page, was the following:
MediaWiki's default page addresses looks like these examples:
http://example.org/w/index.php/Page_title *(recent versions of MediaWiki,
without CGI
<https://en.wikipedia.org/wiki/Common_Gateway_Interface> support)*
http://example.org/w/index.php?title=Page_title *(recent versions of
MediaWiki, with CGI support)*
Our URLs are consistent with the first case and yours are consistent with
the second. However, we do have CGI enabled. Maybe somebody on the list can
elaborate on why the format of the URLs might be different?
Regardless, the best fix for this situation would be for the OpenID Connect
library used by the extension not to strip off the URL parameters. Yes, please
report the second bug you found in the OpenID Connect library directly on
the GitHub page for that library. While you are at it, you could also
report the bug/feature that strips the URL parameters off the redirect URL. In
the meantime, I will add some text to the OpenID Connect extension page
indicating the known bug.
[0] https://www.mediawiki.org/wiki/Manual:Short_URL
Cindy
Date: Fri, 9 Dec 2016 14:48:01 -0600
> From: Scott Koranda <skoranda(a)gmail.com>
> To: mediawiki-l(a)lists.wikimedia.org
> Subject: Re: [MediaWiki-l] OpenID Connect extension and redirect_uri
> Message-ID: <20161209204801.GA59479(a)paprika.localdomain>
> Content-Type: text/plain; charset=us-ascii
>
> > You are correct: the redirect_uri parameter should be pointing back to
> > Special:PluggableAuthLogin. From your example below, it should look
> > something like:
> >
> > redirect_uri=https%3A%2F%2Fmyserver.org%2Fw%2Findex.php
> > %2FSpecial%3APluggableAuthLogin
> >
> > The redirect_url is computed by the code at [0], which discards all query
> > parameters. As long as you are being redirected to OIDC from
> > https://myserver.org/w/index.php/Special:PluggableAuthLogin, you should
> be
> > fine. If you are being redirected from
> > https://myserver.org/w/index.php?title=Special:PluggableAuthLogin,
> however,
> > the title would be stripped off.
> >
> > PluggableAuth is redirected from Special:UserLogin to
> > Special:PluggableAuthLogin by creating the URL at [1] using
> >
> > Title::newFromText( 'Special:PluggableAuthLogin' )->getFullURL()
> >
> > and then being redirected to it. Could getFullURL() be generating the URL
> > in "?title=..." form on your server? Perhaps because of [2]? If so,
> please
> > let me know. There would have to be a fix to prevent the title query
> > parameter from being stripped.
>
> Thank you Cindy. That was the hint I needed.
>
> Although I have experience with OIDC I am new to MediaWiki and
> I had not yet configured "short URLs". After making the
> necessary changes in my Apache HTTP Server and MediaWiki
> configurations to support short URLs the extension then began
> to generate a correct redirect_uri value.
>
> Should the use of short URLs be mentioned as a requirement for
> the OpenID Connect extension, or is it the case that not using
> short URLs is so rare as to not warrant mentioning it
> explicitly?
>
> I now have the extension interoperating with my desired OP
> (not Google FWIW). I did, however, find a small bug.
>
> The OP returns an authorization code value that is a URI. As
> such it is URL-encoded in the POST body being sent back to the
> extension. The extension, however, does not URL-decode the
> value so when it later attempts to exchange the code for the
> ID token it correctly URL-encodes the code but now it is
> "double encoded" and rejected by the OP.
>
> It appears that this is really an issue in the OpenID Connect
> PHP library that the OpenID Connect extension includes. Should
> I open an issue directly with that project or as the extension
> author would you prefer to do that? Or should I just open an
> issue for the OpenID Connect extension?
>
> Thanks,
>
> Scott K
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> MediaWiki-l mailing list
> MediaWiki-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>
>
> ------------------------------
>
> End of MediaWiki-l Digest, Vol 159, Issue 7
> *******************************************
>
Apologies for the cross-posting. Please help spread the word!
Dear MediaWiki admins, developers, and users. We are excited to bring you
the Enterprise MediaWiki Conference this Spring in McLean, VA. To make the
best event possible, we need your help! Please propose a talk on the event
page. [0]
Suggested topics for talks include:
* Examples of use of MediaWiki in organizations
* Lessons learned and challenges in the use of MediaWiki and MediaWiki
extensions in organizations
* Gamification and other incentives for wiki contributions
* Wikitext patterns and wiki design patterns
* Wiki development frameworks
* MediaWiki extension usage and development
* New extensions, extension updates, and ideas for future extensions
For inspiration, see last year’s presentations. [1]
Please do add a title, a brief description and your name. If you don’t have
a full abstract prepared at this time we’ll contact you as the event
approaches.
If you have a full presentation ready (you overachiever you!) feel free to
create a page and add a link.
Presentations will be recorded and made available after the conference.
== Registration ==
Registration for EMWCon is now open! [2] Tickets are on sale through
Eventbrite. There is a discount rate for students and freelancers
available. This rate ends on 25 January.
== Important Facts =
Dates: 8-10 March 2017
Location: McLean, VA, USA at MITRE, a not-for-profit organization that
manages Federally Funded Research and Development Centers (FFRDCs)
sponsored by the US federal government.
----
[0] https://www.mediawiki.org/wiki/EMWCon_Spring_2017
[1] https://www.mediawiki.org/wiki/EMWCon_Spring_2016#Program
[2] https://www.eventbrite.com/e/emwcon-spring-2017-tickets-30356020675
If you have any questions please feel free to reach out. Thank you for your
interest and I hope to see you in the Spring!
Yours,
Chris Koerner
Program Chair
We are currently using MW 1.26.2. After we login to MediaWiki, the monobook skin displays the
login name in the upper right hand corner. We would like to display the Real Name from the user's
preferences instead. We don't want to rename the profile or anything, it's just this one little place
where we would like to see the Real Name up in the corner of the skin there.
Does anyone know of a simple hack to do this for this version?
tx,
L
After I installed MediWiki 1.28 I am getting the following error:
*Parse error*: syntax error, unexpected '[' in *E: ...
\wwwroot\w5\mw-config\index.php* on line *63*
Please help
- Bri
You are correct: the redirect_uri parameter should be pointing back to
Special:PluggableAuthLogin. From your example below, it should look
something like:
redirect_uri=https%3A%2F%2Fmyserver.org%2Fw%2Findex.php
%2FSpecial%3APluggableAuthLogin
The redirect_url is computed by the code at [0], which discards all query
parameters. As long as you are being redirected to OIDC from
https://myserver.org/w/index.php/Special:PluggableAuthLogin, you should be
fine. If you are being redirected from
https://myserver.org/w/index.php?title=Special:PluggableAuthLogin, however,
the title would be stripped off.
PluggableAuth is redirected from Special:UserLogin to
Special:PluggableAuthLogin by creating the URL at [1] using
Title::newFromText( 'Special:PluggableAuthLogin' )->getFullURL()
and then being redirected to it. Could getFullURL() be generating the URL
in "?title=..." form on your server? Perhaps because of [2]? If so, please
let me know. There would have to be a fix to prevent the title query
parameter from being stripped.
Cindy
[0]
https://github.com/jumbojett/OpenID-Connect-PHP/blob/master/OpenIDConnectCl…
[1]
https://phabricator.wikimedia.org/diffusion/EPLG/browse/master/PluggableAut…
[2] https://www.mediawiki.org/wiki/Manual:$wgUsePathInfo
Hello,
>
> I am using MediaWiki version 1.27.1 with the OpenID Connect
> extension detailed at
>
> https://www.mediawiki.org/wiki/Extension:OpenID_Connect
>
> I have configured the extension and when I click on "Log in" I
> am taken to
>
> https://myserver.org/w/index.php?title=Special:UserLogin&
> returnto=My+Test%3AMain+Page
>
> There I click on "Log in with PluggableAuth" and I am
> redirected to the OIDC OP as I expect.
>
> I noticed, however, that when the extension computes the
> redirect_uri parameter that it includes when it redirects the
> browser to the OP it is
>
> redirect_url=https%3A%2F%2Fmyserver.org%2Fw%2Findex.php
>
> That surprises me. I would have thought that the redirect_uri
> would be to a page where MediaWiki can consume the
> authorization code that is returned by the OP.
>
> After I authenticate with the OP it redirects the browser back
> to the redirect_uri with an authorization code and the correct
> state but then MediaWiki just returns a '200 OK' and the main
> page of the wiki.
>
> It naively appears to me that the redirect_uri being sent to
> the OP is not correct, but I do not see a way to configure the
> extension to override it, and I would not know what value to
> use.
>
> I appreciate any input people have on what I might be doing
> wrong, or how I can further troubleshoot.
>
> Thanks,
>
> Scott K
>
I try to login and create my account I get an error.
Auto-creation of a local account failed: Automatic account creation is not allowed.
Using the admin account I get the same error.
Has anyone figured out how to get this to work in MediaWiki 1.28.0?
Thanks,
Phil
A am currently working on an account creation throttle filter for a private
wiki. using the *action == 'createaccount' *filter I have been able to
successfully limit spam account creations. Is there a way to check the IP
address of someone creating the account to a whitelist so that if there is
a match the filter is ignored? The closest I am seeing is the ip_in_range which
still requires that an IP address be provided.
do we have a guide for using git to check out a complete copy of the
current LTSB? I am in the process of documenting a few things and want to
double check that I am doing it correctly.