So I'm running MediaWiki 1.4.7. My users have been wanting to use the "I
forgot my password so email it to me" button when they forget their
password... unfortunately, it does not work! No erroring, just a message
that claims a message was sent.
Sendmail wasn't even installed on my machine until someone let me know
they were trying to use this feature. I promptly installed sendmail, and
set about looking for some setting or variable in the php to enable the
use of the newly-installed sendmail.
I'm confused. An adventure in searching through meta.wikimedia.org was
fruitless.
Thanks for the help!
Andrew Moll
See http://php.net/mail for info on setting up email on php.
Al.
-----Original Message-----
From: andrew(a)mac-boy.com [mailto:andrew@mac-boy.com]
Sent: Friday, 26 August 2005 9:18 a.m.
To: mediawiki-l(a)Wikimedia.org
Subject: [Mediawiki-l] emailing forgotten passwords
So I'm running MediaWiki 1.4.7. My users have been wanting to use the "I
forgot my password so email it to me" button when they forget their
password... unfortunately, it does not work! No erroring, just a message
that claims a message was sent.
Sendmail wasn't even installed on my machine until someone let me know they
were trying to use this feature. I promptly installed sendmail, and set
about looking for some setting or variable in the php to enable the use of
the newly-installed sendmail.
I'm confused. An adventure in searching through meta.wikimedia.org was
fruitless.
Thanks for the help!
Andrew Moll
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)Wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
While checking out browser issues on mediawiki due to bad edits like
http://en.wikipedia.org/w/index.php?title=Star_Wars_Episode_III:_Revenge_of_
the_Sith&diff=prev&oldid=21694074 it was brought to my attention that lynx
and links were problematic. additional research has shown that w3m also
suffers from this issue in a way that is in some ways more problematic than
how the other browsers suffer. w3m only breaks the edit box text if you
actually edit it meaning its not possible to use say a dummy edit box at
login time to detect if it is in a unicode safe mode.
The issue seems to be that all the browserts listed convert the text to the
users local character set before editing and then convert it back to utf-8
for submission. This leads to breakage of parts of the text that the user
did not intend to edit. This is a major issue for sites like wikis where
browsers are used to edit existing text.
we do have a workaround in place
(http://bugzilla.wikimedia.org/show_bug.cgi?id=2676) for IE mac (where there
is no hope of a fix) and this workaround could be extended to the text based
browsers listed. However i'm reluctant to submit a patch to do that as
afaict all of the aformentioned browsers do have modes in which they can
edit unicode safely. Unfortunately it doesn't seem possible to detect when
they are in such modes. I'm writing this message to ask two questions 1: are
there any ways of detecting if a text browser is safe to edit unicode from
the requests it makes (i couldn't find any) and if not would you be prepared
to agree on a method for indicating you are in a mode that is safe for
editing unicode in future versions of your browsers (possiblly by sending
accept-charset headers with weighting based on the mode).
Wow, that's a faster response than I expected! Great job, and thanks!
I'll use another method next time for security issues. I certainly
appreciate the point about having a patch ready with the announcement. I
didn't find anything on meta that encouraged users to report a security
issue any particular way. I was worried about just posting to the zilla for
fear it would get lost in a sea of requests. One article I found today
suggested posting them to the developer's list. I settled on this list
because it has "security announcements" in it's description. It might be
helpful to have a clear & specific contact point identified (person, private
mailbox etc) for security bugs.
Again, great job!
Jeff
--------------
> (In the future please feel free to report security issues by private
> mail, or private message on IRC. Generally speaking it's nice to have a
> patch ready before public disclosure, even if this is only a few hours.)
--------------
-----Original Message-----
From: mediawiki-l-bounces(a)Wikimedia.org
[mailto:mediawiki-l-bounces@Wikimedia.org] On Behalf Of Brion Vibber
Sent: Wednesday, August 24, 2005 11:51 PM
To: MediaWiki announcements and site admin list
Subject: Re: [Mediawiki-l] Re: Cross Site Scripting bug in 1.5b4
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)Wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
Hi,
Just started with the wiki. The only structure has been inputted by having a (manual edited) page of contants on the main page.
Can anyone point me to examples of more extensive (automated) structuring like using categories, breadcrumbs etc.
What is good practice in this case?
Many thanks.
Marcel
---------------------------------
How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos. Get Yahoo! Photos
Hi All,
I apologize if this isn't the place to report this, but an colleague and I
uncovered a cross site scripting bug that seems to be in the 1.5 branch.
I've seen it in 1.5b4. Exploiting it easy. The contents of the search box
are placed verbatim on the search results page. This means you can place
any HTML you want in the search and up it comes. Since the search
parameters are passed on the URL, it's a no-brainer to create an URL with
offending content. Add the following URL to any 1.5b4 site and you should
see a java script alert box pop up:
index.php/Special:Search?search=%3Cbody+onload%3D%22javascript%3Aalert%28%27
cross+site+script+testing+shows+you+are+vulnerable%27%29%3B%22%3E%3Cb%3E%3Ci
%3Ecross+site+script+test%3C%2Fi%3E%3C%2Fb%3E%3C%2Fbody%3E
As example in the wild (sorry, Gentoo) as of this writing:
http://gentoo-wiki.com/index.php/Special:Search?search=%3Cbody+onload%3D%22j
avascript%3Aalert%28%27cross+site+script+testing+shows+you+are+vulnerable%27
%29%3B%22%3E%3Cb%3E%3Ci%3Ecross+site+script+test%3C%2Fi%3E%3C%2Fb%3E%3C%2Fbo
dy%3E
I have not seen this earlier than the 1.5 branch, and it would seem
Wikipedia and a few others are doing something different from the default
which prevents the issue. One simple workaround is to change the
'searchquery' message to not use the $1 parameter for now.
Keep the faith,
Jeff
I decided to go with the '"short" URL option using redirection in my
Apache server. Following the FAQ instructions I added the appropriate
lines to httpd.conf:
AcceptPathInfo On
Alias /wiki "/var/www/html/pubwiki/index.php"
Alias /index.php "/var/www/html/pubwiki/index.php"
I modified my LocalSettings.php to refer to my "alias" as the
ArticlePath, and I modified the script paths:
# The *real* directory
$wgScriptPath = "/pubwiki";
$wgScript = "$wgScriptPath/index.php";
$wgRedirectScript = "$wgScriptPath/redirect.php";
# The *pseudo* path seen in the URL
$wgArticlePath = "/wiki/$1";
While the URL seems to work and my pages load properly (after clearing
the cache), when someone logs in they cannot access their
"preferences" page. It continues to see them as "not logged in". In
fact, the upper right corner of the page reports them as anonymous (ip
address, "please log in", etc.) even though they can click on 'edit'
and it records their ID.
What am I missing in all this? Why isn't this working?