I am writing a tool to assist me in the deletion of images after they
have been moved to the Commons, but I'm getting a User Agent error.
How do I get my particular user agent unblocked?
The user agent I have set is:
W2WCDA/0.1 (Linux; PHP5 Curl; Wikipedia to Wikimedia Commons Deletion
Assistant; +http://www.allyunion.com/wikipedia/; w:en:User:AllyUnion;
jylee AT cs.ucr.edu)/PHP5-CURL/5.3.2-1ubuntu4.2
Thank you,
Jason Y. Lee
AKA AllyUnion, Wikipedia English Administrator
I propose to raise the default ($wgCookieExpiration) at least to 90
days from current 30.
This setting was supposed to combat leakage of logged in sessions by
making them expire before before an attacker grabs them. However,
cookie expiry does little to stop bad guys and annoys good ones:
* Once you've left a public PC without clicking on "log out", your
session is already compromised, even making cookies session-only won't
help.
* If nobody looks specifically for your session, they can stumble upon
it accidentally, while browsing the same site as you did. Lowish
expiry time can indeed help lessen this possibility, however with
Wikipedia's popularity there's pretty solid chance that someone will
visit it from a public teminal within hours, not days. Less popular
sites are, on the other hand, protected by smaller possibilities of
someone looking for them.
* MediaWiki provides no way to adjust preferences without having an
account, so advice "register and set this or that in 'my preferences'"
is pretty popular these days. However, the need to log in every month
which is mildly annoying for wiki regulars, may have a drastic effect
on casual visitors. "You told me to register and when I did, I had to
relogin after a couple of visits!!1"
Taking this all into account, I see no reason to keep the current
default.
--
Max Semenik ([[User:MaxSem]])
> On Sun, Aug 22, 2010 at 4:24 PM, Michael Walsh
> <bluehairedlawyer [at] gmail> wrote:
> > Could someone please rename Special:OldReviewedPages to
> > Special:PendingChanges.
> >
> > For starters the current is wrong. It actually list old unreviewed pages and
> > not old reviewed pages. Special:PendingChanges would have better name
> > recognition with the feature that it implements, and would do what it says
> > on the box: list changes which are pending.
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l [at] lists
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
>
> Not all wikis uses the Pending Changes model of configuration for
> FlaggedRevs, so the name Special:PendingChanges wouldn't make
> sense there. Something like Special:PagesNeedingReview might
> work for both groups.
>
> -Chad
Hi Chad,
Thanks for the quick response. Would it be possible to set a localised name?
Michael
Hello,
I hope somebody can help me, I'm trying to install CentralAuth on my
wikifarm but I get a strange error and I don't know what I'm missing...
My testsetup contains 4 databases so I made the conf:
$wgLocalDatabases = array(
'wikiweet',
'llamada_intern',
'wikiweet_intern',
'llamada',
'wikiweet_recepten',
);
$wgConf->wikis = $wgLocalDatabases;
$wgConf->suffixes = $wgLocalDatabases;
$wgConf->siteParamsCallback = 'efGetSiteParams';
$wgConf->extractAllGlobals( $wgDBname );
the last lines of my localsettings.php are;
require_once ("/home/CentralAuth/CentralAuth.php");
$wgCentralAuthDatabase = 'shared';
When I try to run:
migratePass0.php<http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/CentralAuth/mig…>or
migratePass1.php<http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/CentralAuth/mig…>
I get this error:
CentralAuth migration pass 1:
Finding accounts which can be migrated without interaction...
Er is een syntaxisfout in het databaseverzoek opgetreden.
Het laatste verzoek aan de database was:
âSELECT
user_id,user_email,user_email_authenticated,user_password,user_editcount
FROM `user` WHERE user_name = 'A verspuy' LIMIT 1 â
CentralAuthUser::localUserDataâ
De database gaf de volgende foutmelding:
â1146: Table 'wikiweet.user' doesn't exist (localhost)â
When I try to use special:MergeAccount
I also got the error that Table wikiweet.user doesn't exist
All databases are localhost, and have the prefix mw_ and I'm sure all
databases contain a user table.
I run the trunk version of mediawiki.
Can somebody give advice?
--
Regards,
Huib "Abigor" Laurens
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Aryeh Gregor <Simetrical+wikilist at gmail.com> wrote:
> As I noted above, there are hash functions whose security is provable
> based on the exact same assumptions used to prove security of various
> popular asymmetric encryption schemes. As I also noted above, there
> are problems with naively trying to use public-key encryption instead
> of hash functions. It makes more sense to just use known-secure hash
> functions directly instead of trying to twist public-key encryption to
> our needs, if we're that worried about Whirlpool (et al.) being broken
> anytime soon.
Password length disclosure can be overcome by padding all password inputs
to the maximum length allowed, as you noted. Practically, though, a scheme
like this adds an extra roadblock (if the key is not just stored in the
database) which an attacker must overcome. Assuming even basic
conscientiousness on the part of the administrator this would add a non-trivial
extra compromise for the attacker to pull off. Getting all Wikipedia password
hashes and going to work on them is just one data dump script bug away, though.
> For what it's worth, even ancient and thoroughly-broken hash functions
> like MD4 don't have readily-usable preimage attacks.
These attacks (typically aimed at digital signatures) do not allow themselves
the luxury of assuming the extremely small pre-image space that is typical for
user-entered passwords, though. This makes brute-force attacks feasible and the
only practical constraint on the attacker becomes the hash function's run time.
Several years ago MD5 was brute-forced on the credit card number space in only
a couple of days. Credit card numbers have ~10^16 permutations; even assuming
strong passwords (upper and lower case letters, digits, and special characters)
that is
only ~70^10 for a "very strong" 10 digit password, or ~10^18 and so of about
equal
complexity.
Mediawiki luckily already salts its password hashes with the user name, which
makes site-wide brute force attacks impractical, though not targeted account
brute force
attacks. Given the stakes involved this is probably sufficiently strong, though
in other contexts
compromising a single account may be unacceptable. And I'm sure one could
perform some interesting social engineering-based attacks as "User:Jimbo Wales"
:-)
Hi
My name is Sanyam Goyal. I have recently finished my gsoc project
"javascript overhaul of
SMW"<http://www.mediawiki.org/wiki/User:Sanyamgoyal>under the guidance
of Yaron Koren. The project was successfully finished as
planned. more information can be found on the status
page<http://www.mediawiki.org/wiki/User:Sanyamgoyal/GSoC2010/Status>
.
Basic Summary is that lot of functionality like autocomplete , float-box,
datepicker, combo-box etc in SMW and its spin-off extensions are
re-implemented using the jQuery library , which is becoming a MW standard
now . Also few new features like autocomplete in Special:Ask , jqPlot and
jqPie in SRF , autoGrow textarea in SF, creating Special:CreateClass more
dynamic, simpledatepicker in SFI etc. have been added as new functionality
again using jQuery only.
I can understand if the wiki-pages looks less informative for now, But I
will try to put more detailed wiki pages soon.
moreover if you have any questions about any functionality or anything in
general, I will be glad to answer.
Thanks
Hope you like the new features.
--
Sanyam Goyal
BTech/Alumni @ IIT Bombay
9343115798
It seems that no one actually announced the creation of the
"newprojects" mailing list yet!
The mailing list[1] is an announcement-only list for new Wikimedia
wikis[2]. The way it works is that the addwiki.php[3] script that
sysadmins use to create the wikis automatically sends a mail to the
list, so (provided there are no bugs with the script) subscribers will
get an e-mail when every Wikimedia wiki is created.
This list should be especially useful for people who need to know when
new wikis are created so that they can update their tools or scripts.
Of course, people who are just interested in knowing about new wikis
are welcomed to subscribe too. :-)
[1]https://lists.wikimedia.org/mailman/listinfo/newprojects
[2]http://meta.wikimedia.org/wiki/Special:SiteMatrix
[3]http://wikitech.wikimedia.org/view/Add_a_wiki
--
Casey Brown
Cbrown1023