TL;DR: Should we merge https://gerrit.wikimedia.org/r/#/c/165979/ and
release it with MediaWiki 1.24?
A lot of sites have used MediaWiki:Common.js and MediaWiki:Common.css to
customize the appearance of their site.
In a recent security release[1], support for JS and CSS with on-wiki
origins was removed from being displayed on the Special:Login and
Special:Preferences page.
Because of how the on-wiki MediaWiki:Common.* pages are used and the
access restrictions on them, I think it is reasonable to allow JS and
CSS from them while continuing to disallow individual's JS and CSS on
the Special:Preferences and Special:Login page.
Alexia filed a bug[2] and Kunal (Legoktm) has provided a patch[3] to allow
site-wide styling back on those pages.
I'd like to merge this, but I want some input from the community and
security people before I do that.
Thanks,
Mark.
(Reply-to set to mediawiki-l.)
Footnotes:
[1] https://bugzilla.wikimedia.org/70672
[2] https://bugzilla.wikimedia.org/71621
[3] https://gerrit.wikimedia.org/r/#/c/165979/
--
Mark A. Hershberger
NicheWork LLC
717-271-1084
On Thu, Nov 6, 2014 at 11:41 AM, Derric Atzrott
<datzrott(a)alizeepathology.com> wrote:
> This seems completely reasonable to me. I'd merge is personally. Is there
> any reason not to?
It's fairly easy to inject javascript via css, so merging that patch
means an admin can run javascript on the login/preferences page, while
we specifically block javascript from Common.js, etc.
For me, I like knowing that when I login on a random wiki in our
cluster, a site admin can't have (maliciously or unintentionally) put
javascript on the login page to sniff my password. I'd prefer Kunal's
patch had a feature flag so we could disable this on WMF wikis, but
sites with robust auditing of their common.css can enable it.
Hello,
I try to get extension FreeMind working
(https://www.mediawiki.org/wiki/Extension:FreeMind).
Runs fine with the updates Gutesork made 2 days ago. But there is still
the uploading problem:
During upload I get the error message:
* This file contains HTML or script code that may be erroneously
interpreted by a web browser.*
There is a workaround:
1. You should always be able to successfully upload a one node default
mindmap. Call this the placeholder.
2. Use locate to discover the directory where Mediawiki stored the
placeholder.
3. Copy the complex mindmap you really want to see in your Mediawiki to
that directory.
4. Overwrite the simple placeholder file with the complex file by using
the exact name of the placeholder.
The workaround is working, but it's not a solution. Has anyone an idea,
how to implement a working upload for "mm" files?
Greetings
Frank
I just wanted to point out that if anyone is a user of dynamic
questions with questycaptcha as per Jamie Thinglestad's implementation
here: http://thingelstad.com/stopping-mediawiki-spam-with-dynamic-questy-captchas/
You may have noticed that recently, the spammers have figured it out
and the new user account logs are filling up.
Well, Jamie has updated his solution:
http://thingelstad.com/updated-dynamic-questy-captchas/
I've implemented it and so far so good.
Note that to get it to work, I had to change the => to => in the
question and answer strings.
Cheers
Bill
I'm getting ready to update my wiki and noticed that extensions are not
declared the same way in LocalSettings.php. I have about 57 extensions, and
all but 7 use 'require_once'
>From a programmatic standpoint, the difference appears to be in how PHP
will handle errors.
>From http://www.w3schools.com/php/php_includes.asp
The require() function is identical to include(), except that it handles
errors differently. If an error occurs, the include() function generates a
warning, but the script will continue execution. The require() generates a
fatal error, and the script will stop.
In the general scheme of things, is one a better practice over the other?
Is it nuanced between extensions in such a way that some extensions need
one over the other?
Yours,
Chris Koerner
clkoerner.com
"Derric Atzrott" <datzrott(a)alizeepathology.com> writes:
>>> TL;DR: Should we merge https://gerrit.wikimedia.org/r/#/c/165979/ and
>>> release it with MediaWiki 1.24?
> This seems completely reasonable to me. I'd merge is personally. Is there
> any reason not to?
The discussion on the bug and the fact that this was in a security
release.
I'll merge it tomorrow for RC.1 unless someone objects or a problem
arises.
Mark.
--
Mark A. Hershberger
NicheWork LLC
717-271-1084
http://www.mediawiki.org/wiki/Manual:$wgEnableImageWhitelist
Not ideal but it is an alternative and if you regex your domain(for safety) it will display images. You will loose the benefits of File: and the extras, image props, history, revert and easily resizing.
If you're scripting the images from something like Selenium, set size, look, etc, lots of images and often it might make it easier.
Tom
> On Nov 5, 2014, at 9:50 AM, JFC Morfin <jefsey(a)jefsey.com> wrote:
>
> At 15:18 05/11/2014, John wrote:
>> Content-Transfer-Encoding: base64I would still recommend the same approach as I did previously. Otherwise
>> you are going to have serious database problems. If you can get them all
>> available on the webserver file system use importImages.php from
>> /maintenance for mass uploading
>
> I am going to consider and test this.
> Thank you!
> jfc
>
>
>> On Wed, Nov 5, 2014 at 9:08 AM, Jefsey <jefsey(a)jefsey.com> wrote:
>>
>> ]MH
>> KÌLKÌMÚÜÀte:
>> >
>> >> Content-Transfer-Encoding: base64
>> >Ú
>> > Thank you for the response. But I have scores of files to maintain through
>> > synchronizing scripts. I cannot manage them through uploads. Moreover that
>> ÛÛYH\HÛe same computer at another place. I suppose I have to go
>> > through the nightmare you announce ... Where the solution could be detailed
>> > ]YH\ÙH][H[ÜÝ simple way.
>> >
>> > 1. I have a file under /jefsey/graphs/xxxx.jpg.
>> H]HHÚZÚH[\ÚÛYKÛ[YKÝÝÝÈÚ]]È/home/name/www/images
>> > directory.
>> ÝÈØ[HXZÙHÖÑile:xxxx.jpg]] display the file?
>> > Or another command do itÜX^HH\È\HH\Ý[ÜH\ÜX]HÈ\ÚÀ for such a solutionY\[Ü£à£â÷P are asking for a headache, My suggestion is to enable file uploads but
>> >> restrict it to a special user group and have yourself as they only member
>> âöâvVBÂæ÷bRÂ014 at 8:26 AM, JFC Morfin <jefsey(a)jefsey.com> wrote:
>> >>
>> >> H[ieved that if I installed a xxxx.jpg file in the /images directory it
>> >> > would be accessible through the [[File:xxxx.jpg]]. It does seem to be
>> >> the
>> >0æ0æP0¨Àâ'fRæ÷BVæled uploading. Which parameter should I aad in
>> >> ØØ[Ù]tings.php for [[File:xxxx.jpg]] to work
>> >Wñhpç0âðภ«Ââ( ¢¸l9|9|9|9|9|9|9|9|9|9|9|9|0××××××××××××××××××××××××××××××××À_
>> >> YYXUÚZÚK[XZ[[È\ÝFòVç7V'67&&RÂvòFó £âttps://lists.wikimedia.org/
>> XZ[X[Û@stinfo/mediawiki-l
>> >õõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõð_______________
>> >YYXUÚZÚK[XZ[[È\ÝâFòVç7V'60ribe, go to:
>> >ÎËÛ\ÝËÚZÚ[YYXKÜËÛXZ[X[Û\Ý@nfo/mediawiki-l
>> >õõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõð_______________
>> > MediaWiki-l mailing list
>> > To unsubscribe, go to:
>> ÎËÛ\ÝËÚZÚ[YYXKÜËÛXZ[X[Û\Ý[À/mediawiki-l
>> >
>> _______________________________________________
>> MediaWiki-l mailing list
>> To unsubscribe, go to:
>> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>
>
> _______________________________________________
> MediaWiki-l mailing list
> To unsubscribe, go to:
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
At 15:18 05/11/2014, John wrote:
>Content-Transfer-Encoding: base64I would still recommend the same
>approach as I did previously. Otherwise
>you are going to have serious database problems. If you can get them all
>available on the webserver file system use importImages.php from
>/maintenance for mass uploading
I am going to consider and test this.
Thank you!
jfc
>On Wed, Nov 5, 2014 at 9:08 AM, Jefsey <jefsey(a)jefsey.com> wrote:
>
>]MH
>KÌLKÌMÚÜÀte:
> >
> >> Content-Transfer-Encoding: base64
> >Ú
> > Thank you for the response. But I have scores of files to maintain through
> > synchronizing scripts. I cannot manage them through uploads. Moreover that
>ÛÛYH\HÛe same computer at another place. I suppose I have to go
> > through the nightmare you announce ... Where the solution could be detailed
> > ]YH\ÙH][H[ÜÝ simple way.
> >
> > 1. I have a file under /jefsey/graphs/xxxx.jpg.
>H]HHÚZÚH[\ÚÛYKÛ[YKÝÝÝÈÚ]]È/home/name/www/images
> > directory.
>ÝÈØ[HXZÙHÖÑile:xxxx.jpg]] display the file?
> > Or another command do itÜX^HH\È\HH\Ý[ÜH\ÜX]HÈ\ÚÀ for
> such a solutionY\[Ü£à£â÷P are asking for a headache,
> My suggestion is to enable file uploads but
> >> restrict it to a special user group and have yourself as they only member
>âöâvVBÂæ÷bRÂ014 at 8:26 AM, JFC Morfin <jefsey(a)jefsey.com> wrote:
> >>
> >> H[ieved that if I installed a xxxx.jpg file in the /images directory it
> >> > would be accessible through the [[File:xxxx.jpg]]. It does seem to be
> >> the
> >0æ0æP0¨Àâ'fRæ÷BVæled uploading. Which parameter should I aad in
> >> ØØ[Ù]tings.php for [[File:xxxx.jpg]] to work
> >Wñhpç0âðà¸
> «Ââ( ¢¸l9|9|9|9|9|9|9|9|9|9|9|9|0××××××××××××××××××××××××××××××××À_
> >> YYXUÚZÚK[XZ[[È\ÝFòVç7V'67&&RÂvòFó £âttps://lists.wikimedia.org/
>XZ[X[Û@stinfo/mediawiki-l
> >õõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõð_______________
> >YYXUÚZÚK[XZ[[È\ÝâFòVç7V'60ribe, go to:
> >ÎËÛ\ÝËÚZÚ[YYXKÜËÛXZ[X[Û\Ý@nfo/mediawiki-l
> >õõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõð_______________
> > MediaWiki-l mailing list
> > To unsubscribe, go to:
>ÎËÛ\ÝËÚZÚ[YYXKÜËÛXZ[X[Û\Ý[À/mediawiki-l
> >
>_______________________________________________
>MediaWiki-l mailing list
>To unsubscribe, go to:
>https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
I would still recommend the same approach as I did previously. Otherwise
you are going to have serious database problems. If you can get them all
available on the webserver file system use importImages.php from
/maintenance for mass uploading
On Wed, Nov 5, 2014 at 9:08 AM, Jefsey <jefsey(a)jefsey.com> wrote:
> At 14:41 05/11/2014, John wrote:
>
>> Content-Transfer-Encoding: base64
>>
>
> John,
>
> Thank you for the response. But I have scores of files to maintain through
> synchronizing scripts. I cannot manage them through uploads. Moreover that
> some are on the same computer at another place. I suppose I have to go
> through the nightmare you announce ... Where the solution could be detailed
> ?
>
> Let me phrase it in the most simple way.
>
> 1. I have a file under /jefsey/graphs/xxxx.jpg.
> 2. I have a wiki under /home/name/www with its /home/name/www/images
> directory.
>
> How can I make [[File:xxxx.jpg]] display the file?
> Or another command do it?
>
> Or may be is there a list more appropriate to ask for such a solution?
>
> Deep thanks.
> jfc
>
>
>
> You are asking for a headache, My suggestion is to enable file uploads but
>> restrict it to a special user group and have yourself as they only member
>>
>> On Wed, Nov 5, 2014 at 8:26 AM, JFC Morfin <jefsey(a)jefsey.com> wrote:
>>
>> H™[ieved that if I installed a xxxx.jpg file in the /images directory it
>> > would be accessible through the [[File:xxxx.jpg]]. It does seem to be
>> the
>> Ø\Ù@£â'†fRæ÷BVæled uploading. Which parameter should I aad in
>> ØØ[Ù]tings.php for [[File:xxxx.jpg]] to work?
>> Y\[šÜË€ jfc
>> ‚ ˆ×××××××××××××××××××××××××××××××××××××××××××××À_
>> YYXUÚZÚK[XZ[[™È\Ý‚FòVç7V'67&&RÂvòFó £â€ttps://lists.wikimedia.org/
>> mailman/listinfo/mediawiki-l
>>
>> _______________________________________________
>> MediaWiki-l mailing list
>> To unsubscribe, go to:
>> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>>
>
>
> _______________________________________________
> MediaWiki-l mailing list
> To unsubscribe, go to:
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>