--- Tong Sun wrote:
> Moreover, I saw the following from the rendered
> sandbox page:
>
> ------------------------------------------
> <!-- Head Scripts -->
> <script type="text/javascript"
>
src="/kb/extensions/CategoryTree/CategoryTree.js"></script>
> <script type="text/javascript">
I mean the rendered sandbox page source.
Moreover, AJAX is working fine for my browser.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Hello,
We're using MediaWiki: 1.5.8 to run an internal corporate wiki, and have it
locked down with our Lotus Notes LDAP. However, I also want the sysops to
be able to manually create accounts for a few of our corporate folks who
are not on our Lotus Notes LDAP.
The Admin instructions at http://meta.wikimedia.org/wiki/Preventing_Access
indicate to do this by:
* Note: New users will still be able to be created by sysops, in the
following manner:
Go to [[Special:Userlogin]], when logged in as a sysop. The link to
this page differs from language, (f.ex. in Dutch it is
[[Special:Userlogin]]). Enter a username and an email address, and click
the "by email" button. The account will be created with a random password
which is then emailed to the given address.
However, there is no "by email" button on my Special:Userlogin page, only
the Login button, so my sysops cannot manually create new non-LDAP
accounts.
Any advise is appreciated.
Thank you!
Colleen Robledo
Newsroom Systems Specialist
The Orange County Register/Freedom Orange County Information
625 N. Grand Ave., Santa Ana, CA 92701
Phone: 714/796-2254
Hi,
We use in our office Powerdocs from Hummingbird as our Document Managment
Systen. Well I'm not that happy with it but anyway.
With that system I can create kind of a "reference file" called *.drf,
double click that file opens the corresponding application with the current
version of the document.
Now I'm trying to create that new MIME Type and aswell to change the upload
Special Page to upload such *.drf files.
But
1) Its always Image:xxxxx.drf
2) it would be cool to have it [DM:xxxx.drf] to integrate it to a Wikipage.
Is that a big thing?
Cheers,
Oliver
> >Did you put a .htaccess in your root web directory?
> There is a file named htaccess in my root directory, but I
> don't know what it is or how it got there. I used MS
> Frontpage to write the original website, and I am trying to
> add a wiki section to that site. I'm far from savy when it
> comes to HTML. Should I edit or delete this file to fix my
> problem? I guess another question is if Wiki and Frontpage
> are compatible, or is the wiki treated like a stand alone
> site just linked off of the main site but having no interaction?
Well, you can try to rename this .htaccess to something and see if you
still have the error 500 ?
"Les informations contenues dans ce message electronique peuvent etre de nature confidentielles et soumises a une obligation de secret. Elles sont destinees a l'usage exclusif du reel destinataire. Si vous n'etes pas le reel destinataire, ou si vous recevez ce message par erreur, merci de le detruire immediatement et de le notifier a son emetteur."
"The information contained in this e-mail may be privileged and confidential. It is intended for the exclusive use of the designated recipients named above. If you are not the intended recipient or if you receive this e-mail in error, please delete it and immediately notify the sender."
So I've decided to disable IP edits for my wiki. Easy enough, but the
results are less than satisfactory aesthetically: The "edit" link remains at
the top of the screen for unregistered users, and they get a jarring error
message when they click on it. (I could probably tweak that to give them an
option to view the source, but the edit link would still be there.) That's
using the "typical" method of doing this. I also found some code (
http://meta.wikimedia.org/wiki/Preventing_Access#Questions scroll down a
little bit) that does this by essentially making all pages protected with
regards to unregistered users:
function fnMyUserCan($title, $user, $action, $result)
{
if (($action == 'edit') && $user->isAnon())
$result = false;
}
$wgHooks['userCan'][] = 'fnMyUserCan';
The problem with this method is that it shows the same "view source" button
(and the same tooltip for it), and the same destination page for that, as
would be shown if the page really were protected! This means that I would
have to change the "view source" page to say, "well, this page could be
protected, or it could be semi-protected, or it could just be that you need
to login; I really can't tell you which." That might seem rather
complicated to a reader.
So, is there any way I can rewrite the second method to use a separate "view
source" button (which could have its own tooltip) and a separate "you need
to log in to edit, but here's the source" page for its destination?
Did you put a .htaccess in your root web directory ? Are you using some extra extentions loaded in Apache like mod_security or in PHP like safe_mode or so ?
Check your Apache error log and paste them here (do something like this tail -f /var/log/apache2/error.... Or /var/log/httpd/error...) And refresh your wiki page, the lines will appear
Thanks,
Johan
> -----Message d'origine-----
> De : mediawiki-l-bounces(a)lists.wikimedia.org
> [mailto:mediawiki-l-bounces@lists.wikimedia.org] De la part de Jim Hu
> Envoyé : mardi 17 avril 2007 03:51
> À : MediaWiki announcements and site admin list
> Objet : Re: [Mediawiki-l] New to this.
>
> It looks like you put the LocalSettings.php file outside the
> wiki directory. It goes inside, just not in the config
> directory where it gets written.
>
> Jim
>
> On Apr 16, 2007, at 6:52 PM, Fred Bauder wrote:
>
> >
> >> -----Original Message-----
> >> From: Mike [mailto:xclbur5150@yahoo.com]
> >> Sent: Monday, April 16, 2007 04:35 PM
> >> To: 'MediaWiki announcements and site admin list'
> >> Subject: [Mediawiki-l] New to this.
> >>
> >> I know part of the requirements for asking questions on this list
> >> are to know what you are talking about, but unfortunately I don't
> >> follow directions too well ;) I hope someone can help me anyways.
> >>
> >> I just finished installation of Media wiki. I copied the
> >> localsettings.php file to the parent directory, and followed the
> >> link that it gave me which brought me to my new blank wiki.
> >> Before I had a chance to do anything I accidentally closed the
> >> browser window. Now I cannot get into the wiki. It is saying
> >> there is an internal server error or misconfiguration. Here is a
> >> link to the page with the error. www.drsecrets.com/wiki
> >>
> >> Does anyone know how I managed to screw this up? And more
> >> importantly how I go about fixing it?
> >>
> >> Thank you very much!
> >> Mike
> >
> > http://www.drsecrets.com/LocalSettings.php provides some clues,
> > perhaps permissions are not right.
> >
> > Fred
> >
> >
> >
> > _______________________________________________
> > MediaWiki-l mailing list
> > MediaWiki-l(a)lists.wikimedia.org
> > http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>
> =====================================
> Jim Hu
> Associate Professor
> Dept. of Biochemistry and Biophysics
> 2128 TAMU
> Texas A&M Univ.
> College Station, TX 77843-2128
> 979-862-4054
>
>
> _______________________________________________
> MediaWiki-l mailing list
> MediaWiki-l(a)lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>
"Les informations contenues dans ce message électronique peuvent être de nature confidentielles et soumises à une obligation de secret. Elles sont destinées à l'usage exclusif du réel destinataire. Si vous n'êtes pas le réel destinataire, ou si vous recevez ce message par erreur, merci de le détruire immédiatement et de le notifier à son émetteur."
"The information contained in this e-mail may be privileged and confidential. It is intended for the exclusive use of the designated recipients named above. If you are not the intended recipient or if you receive this e-mail in error, please delete it and immediately notify the sender."
Hello List,
We have written a MediaWiki extension for Krb5 Single Sign-On (SSO)
that uses our Plexcel PHP extension. I have created an extension page
in the usual way:
http://www.mediawiki.org/wiki/Extension:Plexcel
The extension works great but we had to add the AuthPlugin initialization
to includes/Setup.php. We feel this procedure is sub-optimal so I would
like to explain why this was necessary hoping that a future version of
MediaWiki might improve this use-case (or at least no break it).
First, let me explain a little about what SSO means with respect to our
plugin. When a user logs into their IntrAnet workstation (e.g. Windows
XP) in the morning they enter their credentials and get a special Keberos
ticket. For the duration of their login session that ticket can be used
to authenticate with other Kebreros protected resources. Our plugin acts
as a Kerberos authentication acceptor for web clients that can perform
raw Kerberos or SPNEGO. The protocol sequence is as follows:
When a client visits a Kerberos protected site (e.g. MediaWiki with our
plugin) the request is rejected with 401 Unauthorized and a special
WWW-Authenticate: Negotiate header. This indicates to the client
(e.g. IE on XP) that Integrated Windows Authentication (IWA) should be
performed (IWA is Microsoft's way of saying SPNEGO negotiated NTLMSSP
or Kerberos which for most people it basically means Kerberos). Provided
the client's settings are suitable for performing Kerberos and they have
the appropriate tiicket the request will be resubmitted with a special
Authenticate: Negotiate <base64encodedblob> header. This blob of data
is consumed, used to authenticate the client and extract information
about the user such as their full name and what groups they are in.
There are several issues that arise when integrating Kerberos SSO into
an application like MediaWiki. First, notice that two HTTP requests are
required to fetch a page. This happends with EVERY SINGLE PAGE. Also, when
the base 64 authentication header is accepted it must be processed after
the necessary user infrastructure has been initialized because it will
need to query/create the user's MW account and update the login status.
For the above reasons, currently, the PlexcelPlugin class needs to be
initialized and invoked in includes/Setup.php around line 170 after the
StubUser is created. Invoking it before that location generates an error
because the StubUser is required to simulate the "login" of an SSO client.
I have ideas about how this use-case might be improved but I would first
like to hear if anyone is interested in all of this and if they have
any recommendations.
Mike
--
Michael B Allen
PHP Active Directory Kerberos SSO
http://www.ioplex.com/
>-----Original Message-----
>From: Amitrajit Chatterjee [mailto:amitrajit.chatterjee@csueastbay.edu]
>Sent: Tuesday, April 17, 2007 04:07 PM
>To: 'MediaWiki announcements and site admin list'
>Subject: Re: [Mediawiki-l] ProtectSection.php extension
>
>Hi,
>This seems to work for people who are not logged in but is there a way to
>protect my sections/articles from other logged in users ?
>
>Thanks,
>Amit
>
>--------------------------------------------------------------
>Amitrajit Chatterjee
>University Library Systems
>California State University East Bay
>25800 Carlos Bee Blvd,
>Hayward, CA 94542.
>Phone: 510-885-2990
My test shows that it does work to prevent ordinary logged in users from editing the section. And anon ips, but not sysops.
Fred
I meant to do this months ago but just got around to it today. I put
a page for ProtectSection.php up on mediawiki.orghttp://www.mediawiki.org/wiki/Extension:ProtectSection
it links to the svn version and has the code for my modified version
on the page. Originally written by ThomasV... I just tweaked it.
For those who don't already know, ProtectSection.php allows you to
block editing of text between <protect></protect> tags from editing
by anyone who is not a sysop or a bureaucrat (these group permissions
can be modified in the code). My modification suppresses the section
edit link for subsections inside protect tags - it may not work
properly with caching, but I don't have squid running for my wikis so
I can't test that.
=====================================
Jim Hu
Associate Professor
Dept. of Biochemistry and Biophysics
2128 TAMU
Texas A&M Univ.
College Station, TX 77843-2128
979-862-4054