Hello!
We have an intranet we would like to somewhat integrate a copy of
mediawiki into.. at least to the extent that when a user is logged
onto our intranet and they browse to the wiki they would be logged in
there too.
I have control over essentially all of the code for our intranet (php,
uses php sessions for logins, mysql database) and for the mediawiki
install, so I just need to figure out how to pass information via a
cookie or a session or a $_REQUEST variable that can be captured by
the wiki as proof that the user is logged in; alternate to it's own
session info.
Does anyone have any ideas on how the problem might be approached?
Thanks!
- - Jesse Thompson
Webformix, Bend Or
Dear MediaWiki-l(a)Wikimedia.org ,
We are in the very beginning stages of building our own Non-Profit
organization to help bring all green information into one centralized
location. Our goal is to make it easy for the average person to
understand how to be greener in their own lives and how their decisions
effect the world we all live in.
We are working towards this goal by developing GreenZones and
GreenZones.org.
GreenZones will be the physical Zones throughout the world, where
people can come and experience green living and green ideas.
GreenZones.org will be the central location of all green information,
streaming shows, education and communities.
One of the sections within GreenZones.org is called G.Knowledge. The
collective brain for the entire world on Green Technologies, ideas,
information, news, and more. The goal is to use this information to
help protect the planet and improve everyones quality of life on the
planet.
Wikipedia's engine is exactly the same thing but for a much broader
subjects. We would like to build in Wikipedia-Green into
GreenZones.org.
Because we are in such an early stage of development, we have no
technical staff to run the servers or to install / maintain Wikimedia
engine. We currently host with Spymac, which is running on Linux
servers.
Would anyone be interested in helping us build Wiki into our site
GreenZones.org?
Like the other Wiki sites, we would like the Green Version to be
connected to the larger Wiki community to make sure all the information
and content is available to everyone, everywhere in the world. But at
the same time, focus our content from our users to make it easy to
learn about everything green.
Please visit our Beta Site: http://greenzones.org
or go straight to the G.Knowledge demo page:
http://www.greenzones.org/knowledge/index.html
Thank you for any and all help you maybe able to provide.
Christopher Adjani
christopher(a)greenzones.org
Christopher Adjani - GreenZones.org
---------------------------------------------------------------------
http://www.greenzones.org
Hi Colin,
actually it is pretty easy to tweak the wiki so that only people you give permission can write and read. I have set up a wiki for internal use for our organisation, which can be reached within the netwerk as well from the outside (routed an ip-adress to the wiki on the server with apache).
--------------
1. Limit write acces: i haven't figured out on local network level, instead, only people who have an account can write and read and control who can make users.
>From http://meta.wikimedia.org/wiki/Setting_user_rights_in_MediaWiki:
Configuring access restrictions to your wiki
Also see Preventing_Access You can customise user restrictions by placing some or all of the commands below into LocalSettings.php.
# Specify who can edit: true means only logged in users may edit pages
$wgWhitelistEdit = true;
# Pages anonymous (not-logged-in) users may see
$wgWhitelistRead = array ("Main Page", "Special:Userlogin", "Wikipedia:Help");
# Specify who may create new accounts: 0 means no, 1 means yes
$wgWhitelistAccount = array ( 'user' => 0, 'sysop' => 1, 'developer' => 1 );
2. Create a user with sysop rights with the following sql query:
mysql> UPDATE user SET user_rights='bureaucrat,sysop' WHERE user_name='The Username';
The "user" in the above text is the user table in the wikidb database.
The user_rights field is actually a comma-separated list; presently four values are recognized by the software:
The Username is the person you want to give sysop rights.
3. If you want to add users, login with sysop rights and find the page Special:Userlogin and create a new user.
----------------
People from the outside still can see the frontpage, but can't read, edit or create an account.
Good luck!
Geert
-----Oorspronkelijk bericht-----
Van: mediawiki-l-bounces(a)Wikimedia.org
[mailto:mediawiki-l-bounces@Wikimedia.org]Namens Terry Jones
Verzonden: vrijdag 12 november 2004 22:39
Aan: MediaWiki announcements and site admin list
Onderwerp: Re: [Mediawiki-l] limiting write access to a media wiki
>>>>> "Colin" == Colin Johnson <colinj(a)ccs.neu.edu> writes:
Colin> I'm working on building a set of howtos for the users here. I
Colin> like the format and control that a mediawiki gives me. What I
Colin> want to do is be able to limit who has write access to the wiki
Colin> and from where.
Colin> I'd like to be able to do the following:
Colin> 1. limit write access to machines only on our local network
Colin> 2. limit write access to users who login so we can track changes
Colin> 3. limit user accounts to specific people.
Colin> I'm working at a college of computer science and so I don't
Colin> want to, right off the bat, enable all of the students with
Colin> write access. I would like to get there eventually but I'd like
Colin> to start out with only a small number of users who have write
Colin> access and then grow that group over time.
Hi Colin.
I'm not going to try to answer your questions, but instead make a few
comments that you might consider.
The main suggestion is that you consider letting the wiki be open
initially and shutting off access as need be, rather than locking it
down from the outset with a plan to selectively open it. I think a far
more interesting and potentially rich experience is to move (if
needed) from open to closed. There's nothing to be too concerned
about: if it doesn't work, you tighten things up. Lawyers might
disagree, I know. Plus, your aim to develop Howto documents in a wiki
is a perfect scenario for having many people making improvements and
adding information that a few people would take for granted, get
wrong, leave out, under-describe, etc. You can't predict the content
of the wiki, and that's great and well aligned with user manuals (or
howtos) which are notoriously bad at predicting the needs of actual
users. So it feels to me like you've chosen the right tool (the wiki)
and are now looking for a way to (initially) turn off the power it
brings you rather than just letting the thing fly and seeing what
happens. You might be surprised. If you lock it down, the whole
project loses interest, becomes somehow much less attractive, you're
just making another set of manuals.
Here's a perhaps relevant example. I'm teaching a (graduate level,
admittedly) class on computer science theory and algorithms. I set up a
wiki for the class - with just a few basic pages: the syllabus, the
evaluation, some admin details, a page with some of my info on it. I
introduced the wiki on day 1 and pushed them to start using it
(everyone made a page about themselves and linked it in). Plus, each
class has an assigned note taker, and the note taker (and others, of
course) puts stuff into the wiki. The people in the class can do
anything they want to the wiki: change the syllabus, change the page
that says how they will be evaluated, write stuff about each other or
me, deface things, delete things etc. But.... none of this has
happened. I was expecting I'd perhaps have to lock down some pages or
restrict write access to logged-in users, etc., but no. On the other
hand, good things you would not anticipate have happened: students
start taking notes on the class before the class happens! - they're out
there digging up stuff they think is interesting on upcoming subject
and writing and linking it up in the wiki. I go and look at the
syllabus for the day to see what I said I'd teach, and I find notes
already done with stuff someone thinks is important and wants to hear
about. I've had a kid sitting in class taking notes and updating the
wiki as the class happens (while I simultaneously have the wiki up on
an overhead projection system). There are also little things that I
would never have thought of (and didn't have to), like someone putting
a link to the Greek alphabet onto the front page of the wiki - to help
everyone learn the various letters seen in the math. It's pretty cool.
Maybe that's some food for thought for you. And no, you can't have the
URL of the class wiki :-)
Regards,
Terry Jones.
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)Wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
Hello - could somebody point me in the right direction for
finding out what might be wrong with this installation
attempt?
Thanks.
# PHP 4.3.9-1: ok
# PHP server API is apache2handler; ok, using pretty URLs
# (index.php/Page_Title)
# Have XML / Latin1-UTF-8 conversion support.
# PHP's memory_limit is 8M. If this is too low, installation may fail!
# Attempting to raise limit to 20M... ok.
# Have zlib support; enabling output compression.
# Found ImageMagick: /usr/bin/convert; image thumbnailing will be
# enabled if you enable uploads.
# Installation directory: /home/confed/public_html/newwiki
# Script URI path: /newwiki
# Connected as root (automatic)
# Connected to database... 4.0.21-log; enabling MySQL 4 enhancements
# Database confedwiki exists
# There are already MediaWiki tables in this database. Checking if
# updates are needed...
...ipblocks is up to date.
...already have interwiki table
...indexes seem up to 20031107 standards
...have linkscc table.
...linkscc is up to date, or does not exist. Good.
...have hitcounter table.
Converting links table to ID-ID...
Sorry! The wiki is experiencing some technical difficulties, and cannot
contact the database server.
--
Jason Williams <jason(a)andstuff.org.uk>
http://www.andstuff.org.uk/
Hi there,
I am trying to set up a mediawiki with squid as http accellerator,
but I'm only partially succesful. As far as I can judge, the setup
appears to be responding just fine; pages get cached by squid and
when they are edited they are PURGEd from the cache. So far, so good.
However, when I log in, the logged in version of the page gets
cached by my browser, leading to strange effects when logging out.
Returning to the page will display the logged in version even though
I'm not logged in. Refreshing the page in the browser fixes the
problem. I have checked with a second browser; squid is not caching
the logged in version of pages.
The documentation is kind of flimsy (;-)) when it comes to
configuring mediawiki + squid. Most info I found came from:
http://www.aulinx.de/oss/code/wikipedia/http://wiki.aulinx.de/Cache-Control
Any ideas what I am doing wrong in my squid config? Relevant
lines are pasted below:
-------------------------------------------------------------
#We recommend you to use the following two lines.
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY
# Allow access to the web ports
acl web_ports port 80
http_access allow web_ports
# Allow purge
acl purge method PURGE
http_access allow purge localhost
http_access deny purge
# Default match
refresh_pattern . 0 20% 4320
-------------------------------------------------------------
All advice is appreciated.
Greetings,
Patrick
--
_______________________________________________________________
Patrick Atoon ___________________ mailto:patricka@rapdict.org
_____________________________________ http://www.rapdict.org/
>>>>> "Colin" == Colin Johnson <colinj(a)ccs.neu.edu> writes:
Colin> I'm working on building a set of howtos for the users here. I
Colin> like the format and control that a mediawiki gives me. What I
Colin> want to do is be able to limit who has write access to the wiki
Colin> and from where.
Colin> I'd like to be able to do the following:
Colin> 1. limit write access to machines only on our local network
Colin> 2. limit write access to users who login so we can track changes
Colin> 3. limit user accounts to specific people.
Colin> I'm working at a college of computer science and so I don't
Colin> want to, right off the bat, enable all of the students with
Colin> write access. I would like to get there eventually but I'd like
Colin> to start out with only a small number of users who have write
Colin> access and then grow that group over time.
Hi Colin.
I'm not going to try to answer your questions, but instead make a few
comments that you might consider.
The main suggestion is that you consider letting the wiki be open
initially and shutting off access as need be, rather than locking it
down from the outset with a plan to selectively open it. I think a far
more interesting and potentially rich experience is to move (if
needed) from open to closed. There's nothing to be too concerned
about: if it doesn't work, you tighten things up. Lawyers might
disagree, I know. Plus, your aim to develop Howto documents in a wiki
is a perfect scenario for having many people making improvements and
adding information that a few people would take for granted, get
wrong, leave out, under-describe, etc. You can't predict the content
of the wiki, and that's great and well aligned with user manuals (or
howtos) which are notoriously bad at predicting the needs of actual
users. So it feels to me like you've chosen the right tool (the wiki)
and are now looking for a way to (initially) turn off the power it
brings you rather than just letting the thing fly and seeing what
happens. You might be surprised. If you lock it down, the whole
project loses interest, becomes somehow much less attractive, you're
just making another set of manuals.
Here's a perhaps relevant example. I'm teaching a (graduate level,
admittedly) class on computer science theory and algorithms. I set up a
wiki for the class - with just a few basic pages: the syllabus, the
evaluation, some admin details, a page with some of my info on it. I
introduced the wiki on day 1 and pushed them to start using it
(everyone made a page about themselves and linked it in). Plus, each
class has an assigned note taker, and the note taker (and others, of
course) puts stuff into the wiki. The people in the class can do
anything they want to the wiki: change the syllabus, change the page
that says how they will be evaluated, write stuff about each other or
me, deface things, delete things etc. But.... none of this has
happened. I was expecting I'd perhaps have to lock down some pages or
restrict write access to logged-in users, etc., but no. On the other
hand, good things you would not anticipate have happened: students
start taking notes on the class before the class happens! - they're out
there digging up stuff they think is interesting on upcoming subject
and writing and linking it up in the wiki. I go and look at the
syllabus for the day to see what I said I'd teach, and I find notes
already done with stuff someone thinks is important and wants to hear
about. I've had a kid sitting in class taking notes and updating the
wiki as the class happens (while I simultaneously have the wiki up on
an overhead projection system). There are also little things that I
would never have thought of (and didn't have to), like someone putting
a link to the Greek alphabet onto the front page of the wiki - to help
everyone learn the various letters seen in the math. It's pretty cool.
Maybe that's some food for thought for you. And no, you can't have the
URL of the class wiki :-)
Regards,
Terry Jones.
Hello,
Can someone direct to the page that describes the procedure to install MediaWiki and Apache, MySql, and PHP via EasyPHP? I lost the url.
Thanks,
rc
This e-mail contains confidential information that is proprietary to EPCOR and its subsidiary companies in all respects. This information is intended only for the person(s) named in the destination address. Unauthorized distribution, copying or disclosure is strictly prohibited. If you receive this e-mail in error, please delete it immediately.
I'm new to implementing a media wiki so bear with me if what follows
is(are) FAQ(s).
I'm working on building a set of howtos for the users here. I like the
format and control that a mediawiki gives me. What I want to do is be
able to limit who has write access to the wiki and from where.
I'd like to be able to do the following:
1. limit write access to machines only on our local network
2. limit write access to users who login so we can track changes
3. limit user accounts to specific people.
I'm working at a college of computer science and so I don't want to,
right off the bat, enable all of the students with write access. I would
like to get there eventually but I'd like to start out with only a small
number of users who have write access and then grow that group over time.
So, pointers to what I should read to get up to speed on this would be
great.
I do have the wiki set up and running so that's not a problem.
Hi all.
I've got a mediawiki running for a project at sourceforge. Since the project
is technical in nature we need math stuff. I got the binary for texvc from
mediawiki@SF (can't compile it myself at SF) and put it in the ./math/
directory. I also created the math and tmp directories needed.
When I execute texvc in the shell it works fine. I even tried the command and
arguments printed as debug message by Math.php and it works fine. Done this
way the formula is correctly displayed in the wiki page. However, when texvc
is called by Math.php only the .tex file is created and creation of the .png
fails. There is an example at
[http://ltilib.sourceforge.net/mediawiki-1.3.7/index.php/Convolution].
Has anybody seen behaviour like this before? Any ideas? Thanks for your help,
Peter
Thanks for the link Something I need to read as well, but not the install link I am looking for.
> -----Original Message-----
> From: mediawiki-l-bounces(a)Wikimedia.org [SMTP:mediawiki-l-bounces@Wikimedia.org] On Behalf Of Taneem A T
> Sent: Friday, November 12, 2004 8:12 AM
> To: MediaWiki announcements and site admin list
> Subject: Re: [Mediawiki-l] Change the navigation box
>
> The following link, available from the Mediawiki documentation site,
> contains some helpful tips and examples similar to the type of
> modifications you are asking for:
>
> http://wise-nano.org/w/Programming_notes
>
> (you can also modify the existing links in the nav panel by going to
> the Special: all systems messages page and changing the appropriate
> links there.)
>
> =)
>
> Taneem Talukdar
>
>
> On Fri, 12 Nov 2004 22:37:21 +1000, Adam Parker <cyaegha(a)iinet.net.au> wrote:
> > I'm using the MonoBook skin and would like to add and remove some entries
> > from the 'navigation' box on the left of the page. Where do I do this?
> >
> > -Adam.
> > _______________________________________________
> > MediaWiki-l mailing list
> > MediaWiki-l(a)Wikimedia.org
> > http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
> >
> _______________________________________________
> MediaWiki-l mailing list
> MediaWiki-l(a)Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
This e-mail contains confidential information that is proprietary to EPCOR and its subsidiary companies in all respects. This information is intended only for the person(s) named in the destination address. Unauthorized distribution, copying or disclosure is strictly prohibited. If you receive this e-mail in error, please delete it immediately.