headers
Tisza Gergő | 1 Nov 2010 08:29
Picon
Gravatar

Re: Cross wiki script importing

Raimond Spekking <raimond.spekking <at> gmail.com> writes:

> Try something like
> 
>
importScriptURI('http://ml.wikipedia.org/w/index.php?title=Mediawiki:rules.js‎&action=raw&ctype=text/javascript');

That will break HTTPS security though. I use this script on my home wiki:

function importScriptIw(page, lang, project) {
  if (lang in ['commons', 'meta']) {
    project = 'wikimedia';
  } else { 
    project = project || 'wikipedia';
  }
  if (window.location.protocol == 'https:') {
    var scriptPath = 'https://secure.wikimedia.org/' + project + '/' + lang +
'/w/index.php';
  } else {
    var scriptPath = 'http://' + lang + '.' + project + '.org/w/index.php';
  }
  var uri = scriptPath + ("?title=" + encodeURIComponent(page.replace(/ /g,
"_")).replace(/%2F/gi, "/").replace(/%3A/gi, ":") +
"&action=raw&ctype=text/javascript"); 
  return importScriptURI(uri);
}

importScriptIw('Mediawiki:rules.js‎', 'ml');

_______________________________________________
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nicolas Vervelle | 1 Nov 2010 23:25
Picon

Configuring upload : authorizing some file extensions ?

Hello,

I am the administrator of Jmol wiki, http://wiki.jmol.org, and I am trying
to authorize the upload of files with extensions .pdb, .mol, ... (chemistry
files).
It was working some time ago, but apparently it's not working any more.
I don't know when it stopped working (maybe when upgrading MediaWiki but not
sure at all).

Error message is "File is corrupt or the extension does not match the file
type"

We are currently using MediaWiki 1.14.0 (but I could upgrade if required,
just needs some work to change the Jmol extension to work with 1.16)

Our current configuration is :

In LocalSettings.php :
$wgEnableUploads       = true;
$wgFileExtensions[] = 'cml';
$wgFileExtensions[] = 'ico';
$wgFileExtensions[] = 'mol';
$wgFileExtensions[] = 'pdb';
$wgFileExtensions[] = 'xyz';
$wgTrustedMediaFormats[] = 'chemical/x-pdb';
$wgTrustedMediaFormats[] = 'chemical/x-xyz';

In includes/mime.types :
chemical/x-pdb pdb
chemical/x-xyz xyz
(Continue reading)

Permalink | Reply | 0 comments |
headers
bawolff | 2 Nov 2010 01:09
Picon

Re: Cross wiki script importing

> Message: 11
> Date: Mon, 1 Nov 2010 07:29:18 +0000 (UTC)
> From: Tisza Gerg? <gtisza <at> gmail.com>
> Subject: Re: [Wikitech-l] Cross wiki script importing
> To: wikitech-l <at> lists.wikimedia.org
> Message-ID: <loom.20101101T082118-175 <at> post.gmane.org>
> Content-Type: text/plain; charset=utf-8
>
> Raimond Spekking <raimond.spekking <at> gmail.com> writes:
>
> > Try something like
> >
> >
> importScriptURI('http://ml.wikipedia.org/w/index.php?title=Mediawiki:rules.js?&action=raw&ctype=text/javascript');
>
> That will break HTTPS security though. I use this script on my home wiki:
>
[snip]

May I ask how? If you're logged in to the secure server, then the
cookies won't get transmitted to the unsecure server when loading js
from them. At the very worse (if we really put on our tin foil hats) I
suppose someone could intercept the non-secured js script, do a man in
the middle type thing and replace the script with malicious js.
However if someone actually has the ability to do that, they could
already do that with the geoip lookup. Thus I don't see how doing the
importScriptURI reduces security.

-bawolff
(Continue reading)

Permalink | Reply | 3 comments |
headers
Krinkle | 2 Nov 2010 02:57
Picon
Gravatar

Re: org-mediawiki.el

Op 30 okt 2010, om 18:28 heeft Bastien het volgende geschreven:

> Dear list,
>
> if there are Emacs people among you, they might be interested in  
> testing
> org-mediawiki.el -- a library for Emacs org-mode to convert Org  
> files to
> mediawiki-syntax formatted files:
>
>  http://lumiere.ens.fr/~guerry/u/org-mediawiki.el
>
> org-mediawiki.el uses this experimental export engine:
>
>  http://repo.or.cz/w/org-mode.git/blob_plain/HEAD:/EXPERIMENTAL/org-export.el
>
> 1. Load Emacs
> 2. Edit an Org file and save it
> 3. Load org-export.el
> 4. Load org-mediawiki.el
> 5. M-x org-mw-export
>
> Thanks for any feedback,
>
> PS: sorry if such announcements are a bit off-topic.  Let me know.
>
> -- 
> Bastien

I never work with Emacs, which could mean that the following is
(Continue reading)

Permalink | Reply | 1 comment |
headers
Marco Schuster | 2 Nov 2010 07:10

Re: Cross wiki script importing

On Tue, Nov 2, 2010 at 1:09 AM, bawolff <bawolff+wn <at> gmail.com> wrote:
> May I ask how? If you're logged in to the secure server, then the
> cookies won't get transmitted to the unsecure server when loading js
> from them. At the very worse (if we really put on our tin foil hats) I
> suppose someone could intercept the non-secured js script, do a man in
> the middle type thing and replace the script with malicious js.
> However if someone actually has the ability to do that, they could
> already do that with the geoip lookup. Thus I don't see how doing the
> importScriptURI reduces security.
Firefox and IE will whine that the site attempts to load unsecure
resources. Also, it is indeed possible to transmit cookies; it's
enough that the user has also logged in into the unsecure servers in
the past and is e.g. at a public WiFi hotspot now and so uses the
secure gateway.

Marco

--

-- 
VMSoft GbR
Nabburger Str. 15
81737 München
Geschäftsführer: Marco Schuster, Volker Hemmert
http://vmsoft-gbr.de

_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Permalink | Reply | 1 comment |
headers
K. Peachey | 2 Nov 2010 07:35
Picon
Gravatar

Re: Cross wiki script importing

On Tue, Nov 2, 2010 at 4:10 PM, Marco Schuster
<marco <at> harddisk.is-a-geek.org> wrote:
> Firefox and IE will whine that the site attempts to load unsecure
> resources. Also, it is indeed possible to transmit cookies;
That is because its loading content from our uploads servers (aka
Images), those domains are set not to send/set cookies.
Permalink | Reply | 0 comments |
headers
Aryeh Gregor | 2 Nov 2010 16:55
Picon

Re: org-mediawiki.el

On Mon, Nov 1, 2010 at 9:57 PM, Krinkle <krinklemail <at> gmail.com> wrote:
> But I noticed the table-conversion process is giving it a
> class="WikiTable".
> If I'm not mistaken this should be lowercase class="wikitable" in
> order to work
> with the CSS definitions in MediaWiki.

Yes, classes in HTML are case-sensitive, except in quirks mode:

http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#selectors

So it might work in testing if you don't have a doctype or something,
but not on a normal MediaWiki page.
Permalink | Reply | 0 comments |
headers
Aryeh Gregor | 2 Nov 2010 17:01
Picon

Re: Cross wiki script importing

On Mon, Nov 1, 2010 at 8:09 PM, bawolff <bawolff+wn <at> gmail.com> wrote:
> May I ask how? If you're logged in to the secure server, then the
> cookies won't get transmitted to the unsecure server when loading js
> from them.

Unless you've logged into the insecure server at some point in the past.

> At the very worse (if we really put on our tin foil hats) I
> suppose someone could intercept the non-secured js script, do a man in
> the middle type thing and replace the script with malicious js.
> However if someone actually has the ability to do that, they could
> already do that with the geoip lookup.

True, that's a separate problem.
Permalink | Reply | 0 comments |
headers
Rob Lanphier | 2 Nov 2010 17:51
Picon
Gravatar

Bugzilla keywords for deployment queues?

Hi everyone,

One discussion we had at the Hack-a-ton was about the continued
frustration of getting features deployed to the WMF-operated sites.

Prior to Hack-a-ton, one short-term solution we started work on was
consolidating the review queue into a single place:
http://www.mediawiki.org/wiki/Review_queue

That page still needs some organization and a process around it to
make sure that we're actually looking at the page.  However, our
discussion at Hack-a-ton made it clear that even if we have a
well-tuned process there, we still have features rolling off the end
of that conveyor belt onto the floor.

After review, some (but not all) of the features in the review queue
then need to be reviewed for checking into the deployment branch.  Our
short term answer to that was the deployment queue:
http://www.mediawiki.org/wiki/Deployment_queue

Even then, we're still not done.  We have one more step, which is
launching the feature on one or more wikis.  We could also create
another queue page for that.  However, given the complicated workflow
here, it seems that a wiki is the wrong tool to keep track of this.

My inclination at this point is to augment the list of keywords on
Bugzilla, and use mediawiki.org to document the process, and as a
place to stash the magical queries to pull up the right lists.

We already have the "need-review" keyword.  I suggest we add two more
(Continue reading)

Permalink | Reply | 23 comments |
headers
Robert Leverington | 2 Nov 2010 18:05
Picon

Re: Bugzilla keywords for deployment queues?

On 2010-11-02, Rob Lanphier wrote:
> We'd then pick off the keywords as we step through the process (e.g.
> once it's reviewed, remove the "need-review" keyword).  We could then
> generate three queries to get us the three queues I alluded to above:
> 1.  Issues with all three keywords.  These are features that someone
> would like to see deployed and launched, but needs to be reviewed
> first.
> 2.  Issues with "need-deploy" and "need-enabled".  These are
> extensions that have been reviewed, but need to be checked into the
> production branch
> 3.  Issues with "need-enabled" only.  These are extensions/features
> that just need action from ops.
> 
> Does this make sense?  If so, I'll add the keywords and start
> documenting the process and retrofitting existing feature requests
> into this system.

This sounds like a good idea, however I think it would be better to
only use a single keyword per state - and as each state is completed
it is replaced by the next keyword.  Otherwise you cannot just do a
keyword search for "need-enabled" or "need-deploy" and find just the
ones that can actually be processed.

Additionally, since this system seems to be targetted at extensions, I
think it might be more intuitive to have them labelled as such, i.e.:
 - extension-need-review
 - extension-need-deploy
 - extension-need-enabled
Currently I believe the need-review keyword is used for patches that
need review aswell as extensions, so using a conflicting namespace
(Continue reading)

Permalink | Reply | 1 comment |

Gmane