https://bugzilla.wikimedia.org/show_bug.cgi?id=18492
Could someone with DB and possibly Oracle knowlage take a minute to review this
patch.
I'll try to supply database creation script ASAP (my testing DB server took a
detour trough never never land, will post it when i restore from backup).
k10xbye
Unfortunately, it might be quite hard for MediaWiki admins to set up SSL
comparing to what they do to setup MediaWiki or it's extensions. Looks like
XRDS is "easier" approach to implement.
Sergey
On Sun, Apr 19, 2009 at 3:46 PM, Peter Williams <pwilliams(a)rapattoni.com>wrote:
> This could be interesting of itself in the uci spirit of openid.
>
> One can use yahoos willingess to rely without warning on a https realm as
> an authentication scheme. Yahoo implies that the https cert on an https
> realm is "valid" (wrt its trust list, its handling of crls and arls). A
> reputation service can now crawl which sites yahoo so rates, and publish a
> meta reliance signal (by updating its ocsp database for example). Those rp
> doing discovery on smaller ops might configure their ssl client engines to
> use that ocsp source, when qualifying the original yahoo rp (now acting as
> an asserting or attribute authority/agent of the dataowner (ie the user) ).
>
> ________________________________
> From: Allen Tom <atom(a)yahoo-inc.com>
> Sent: Sunday, April 19, 2009 12:34 PM
> To: Sergey Chernyshev <sergey.chernyshev(a)gmail.com>
> Cc: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>;
> general(a)openid.net <general(a)openid.net>
> Subject: Re: [OpenID] OpenID MediaWiki Extension v.0.8.4.1 - Identity
> Providers UI
>
> Hi Sergey,
>
> The Yahoo OpenID Provider will display a warning to the user if the RP's
> OpenID endpoints are not discoverable.
>
> Warning: This website has not confirmed its identity with Yahoo! and might
> be fraudulent. Do not share any personal information with this website
> unless you are certain it is legitimate.
>
> The best documentation for fixing this issue is here:
> http://blog.nerdbank.net/2008/06/why-yahoo-says-your-openid-site.html
>
> The AOL Sign-in form fails if the user just clicks the Login Button without
> entering their AOL ScreenName. You might want to disable the button until
> after the user types in their ScreenName. This will only be an issue until
> AOL upgrades their OpenID Provider from OpenID 1.1 to OpenID 2.0. Once they
> have OpenID 2.0 support, you'll be able to handle AOL logins identically to
> Google and Yahoo.
>
> Good job!
> Allen
>
>
> Sergey Chernyshev wrote:
> Hi,
>
> I'm done with initial implementation of Identity Providers UI for OpenID
> MediaWiki Extension.
>
> Extension now shows a user-friendly (although my design skills are far from
> perfect) form where they can pick from a list of OpenID providers (generic
> OpenID URL form is still default).
>
> You can see it in action here:
> http://www.mediawikiwidgets.org/Special:OpenIDLogin
> http://www.techpresentations.org/Special:OpenIDLogin (without icons - I'll
> enable them later)
>
> After some discussions and concerns here on the list, I implemented it in
> the way that provider logos don't show up by default and if you would like
> to show them on your site, you have to add:
>
> $wgOpenIDShowProviderIcons = true;
>
> to your LocalSettings.php
>
> Hope you like it, but I'm still open to suggestions about improving the
> interface so you all finally install it on your wikis ;)
>
> Thank you,
>
> Sergey
>
>
> --
> Sergey Chernyshev
> http://www.sergeychernyshev.com/
>
>
>
> ________________________________
>
> _______________________________________________
> general mailing list
> general(a)openid.net<mailto:general@openid.net>
> http://openid.net/mailman/listinfo/general
>
>
>
On Sun, Apr 19, 2009 at 3:34 PM, Allen Tom <atom(a)yahoo-inc.com> wrote:
> Hi Sergey,
>
> The Yahoo OpenID Provider will display a warning to the user if the RP's
> OpenID endpoints are not discoverable.
>
> Warning: This website has not confirmed its identity with Yahoo! and might
> be fraudulent. Do not share any personal information with this website
> unless you are certain it is legitimate.
>
> The best documentation for fixing this issue is here:
> http://blog.nerdbank.net/2008/06/why-yahoo-says-your-openid-site.html
>
Thanks, Tom, I've created a bug in Bugzilla for this:
https://bugzilla.wikimedia.org/show_bug.cgi?id=18527
The AOL Sign-in form fails if the user just clicks the Login Button without
> entering their AOL ScreenName. You might want to disable the button until
> after the user types in their ScreenName. This will only be an issue until
> AOL upgrades their OpenID Provider from OpenID 1.1 to OpenID 2.0. Once they
> have OpenID 2.0 support, you'll be able to handle AOL logins identically to
> Google and Yahoo.
>
It's probably a good idea not to have a button enabled for any of the
providers - created a bug for this one as well:
https://bugzilla.wikimedia.org/show_bug.cgi?id=18528
Good job!
> Allen
>
Thank you,
Sergey
--
Sergey Chernyshev
http://www.sergeychernyshev.com/
Hi,
I'm done with initial implementation of Identity Providers UI for OpenID
MediaWiki Extension.
Extension now shows a user-friendly (although my design skills are far from
perfect) form where they can pick from a list of OpenID providers (generic
OpenID URL form is still default).
You can see it in action here:
http://www.mediawikiwidgets.org/Special:OpenIDLoginhttp://www.techpresentations.org/Special:OpenIDLogin (without icons - I'll
enable them later)
After some discussions and concerns here on the list, I implemented it in
the way that provider logos don't show up by default and if you would like
to show them on your site, you have to add:
$wgOpenIDShowProviderIcons = true;
to your LocalSettings.php
Hope you like it, but I'm still open to suggestions about improving the
interface so you all finally install it on your wikis ;)
Thank you,
Sergey
--
Sergey Chernyshev
http://www.sergeychernyshev.com/
So I was thinking instead of just packaging in jQuery I should package
in / move the entire mv_embed folder into the skins directory .. it does
not make sense to maintain two branches reinventing what mv_embed.js
provides in the process of refactoring other core mediaWiki javascript.
We will have to do something like that eventually anyway if we want to
start including things like the add_media_wizard, firefoog & ajax
copyByUrl status upload helpers, the Kaltura Sequencer etc. If you peek
at the add_media_wizard code (which provides the firefogg upload
helper) you can see its using mv_embed to manage its entry point into
the interface libraries. This will also pave the way for video page
includes to be <video> tags that get rewriten by mv_embed supporting
firefox 3.5 javascript disabled users while retaining fall-backs and a
html interface player for people with javascript turned on.
Mv_embed originally was a library for embedding video but now has
morphed into a library for "embedding javascript interfaces". In essence
this lays the groundwork for a more mash-able future since mediaWIki
interfaces will be "embeddable" into other contexts just like the remote
embedding of the video playback interface works. (ie opencongress embed
metavid videos with their own skin / interface:
http://www.opencongress.org/person/videos/400237_barbara_lee )
The vast majority of "video specific" code has already been factored out
of mv_embed into libEmbedVideo libraries and the rest should be
forthcoming. (reducing core mv_embed size to something pretty minimal)
The scriptLoader approach has enabled the js code to become pretty
modular so it should never result in including lots of js that you don't
need.
== An overview of what core functionality mv_embed supports / stuff we
don't want to maintain in two places:
* the javascript version of wfGetMsg called gM (in mv_embed) .. this
function is simple right now but will get a bit more complicated as we
add more advanced language msg support.
* the mvJsLoader.doLoad helper function that is integrated with script
loader so you can run doLoad('className', function(){ //stuff to run now
that className is available } ... useful for dynamic script includes &
it works well with front-loading libraries you know you will need. For
example if your on a page with a video we can send the necessary
libraries for video interface in the master packaged scriptLoader
request and when the doLoad function is called it will skip the remote
request to get those libs and jump to code it knows it can execute. But
if you hit a video from a different path in the interface where we don't
know if you would need the video lib (ie add_media_wizard could be used
just for grabbing an image instead of a video clip) ... then you load
the library on demand.
* some mediaWiki convenience functions not available in jQuery core
like: do_api_req that lets you contextually get mediaWiki api data given
your context. (ie a add_media_wizard embed in a remote mediaWiki
instance can transparently hit the commons api via json callback while
if your on commons hit the api via ajax request.)
* other convenient function like js_log, js_error, parseURI etc.
* some patches to jQuery plugins that have not made their way upstream.
== Down sides ==
* Ideally we want to keep mv_embed "stand alone" support this involves a
minor bit of trickery in the script server to detect if its in mediaWIki
context or a stand alone package. If stand alone mode we provide logical
entry points for other CMS's or static usage to make use of the code
embedding helper code. Static includes of mv_embed.js (without the
script server & localization) should continue to work fine.
* this will bring a fairly large set of javascript into the distribution
branch not all of which is "stable" but un-stable parts won't be
accessible via the interface. (all the js is already on the live site
under the extensions directory just not evoked)
== Way forward ==
Since mv_embed is already pretty smart about paths and context this is a
really simple change technically involving renaming a path or two.
Other issues to consider is the other php entry points in the mv_embed
folder like sample usage pages and cortado_iframe.php we can probably
disable them for wikimedias usage.
peace,
--michael
It seems this is the place to request commit access, so I'd like to request
commit access too.
My key: http://toolserver.org/~robin/publickey.txt
Commit name: robin (my wikiname is SPQRobin but uppercase appears to be not
allowed)
I want to use it to commit and maintain my extension (see
http://www.mediawiki.org/wiki/Extension:WikimediaIncubator) to be used on
Wikimedia Incubator.
Maybe I'll do some general work/maintenance as well, or fix bugs, when I see
something I can fix.
I have already worked on SpecialInterwiki extension but I didn't work on it
further since I didn't have commit access..
I also used to work a bit on i18n through Translatewiki.net (for example,
reporting unused messages, ...) although that's not so important for this :)
Thank you.
We’re encountering some networking problems between our Tampa and
Amsterdam data centers, which is breaking access to the sites for people
in Europe. Mark’s poking to see if it can be resolved; if necessary
we’ll reroute European visitors directly to the Tampa center.
-- brion
Hello all
At the developer meetup, I announced that Wikimedia Deutschland is offering
contracts for a couple of projects we feel are important. We again invite anyone
to apply NOW for any project that interests you.
The DEADLINE for applying is SUNDAY, APRIL 19!
We did not receive any offer for the most urgent project: Evaluate the impact
of using flagged revisions on the German Wikipedia, see
<http://www.mediawiki.org/wiki/WMDE_contract_offers/Evaluate_the_impact_of_u…>.
We feel that it would be very helpful to run a full analysis on this before the
English language Wikipedia decides on how to implement flagged revisions. It's a
powerful tool, and we should make sure we use it to it's full potential.
Below, the other projects are listed again:
* Rewrite CatScan, a tool for finding pages in a set of categories recursively,
based on various criteria -
http://www.mediawiki.org/wiki/WMDE_contract_offers/Rewrite_CatScan
* Store interwiki-links in the database, just like we already store
interlanguage-links -
http://www.mediawiki.org/wiki/WMDE_contract_offers/Store_interwiki-links_in…
* Improve the Gadgets extension to allow for gadgets to be enabled per default,
be restricted to specific user groups, etc -
http://www.mediawiki.org/wiki/WMDE_contract_offers/Improve_the_Gadets_exten…
* Implement full support for TIFF files, including multi-page TIFFs, similar to
how DjVu is handled -
http://www.mediawiki.org/wiki/WMDE_contract_offers/Implement_full_support_f…
If you would like to help with any of the above, please contact me at
<daniel.kinzler AT wikimedia.de> and provide the following information:
* Your real name and country of residence
* How you plan to go about implementing the desired function
* Any experience working with MediaWiki
* How many working hours you would spend on it, and how much you ask for it
* In what time frame you would be able to do the job
This information is also available at
http://www.mediawiki.org/wiki/WMDE_contract_offers
Thanks you all for your interest!
-- daniel