Subject: Can we change auto-logout timing on wiki.postgresql.org?

From: Josh Berkus <[email-masked]>
Date: Thu, 25 Apr 2013 17:42:30 -0700

WWW,

wiki.postgresql.org is auto-logging me out after an hour, or less.  This
is irritating when I'm editing a really long wiki page.  Could we please
set it to something like 8 hours?

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

-- 
Sent via pgsql-www mailing list ([email-masked])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

---

From: David Fetter <[email-masked]>
Date: Thu, 25 Apr 2013 19:21:52 -0700

> set it to something like 8 hours?

+1 :)

Cheers,
David.
-- 
David Fetter <[email-masked]> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: [email-masked]
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

---

From: Magnus Hagander <[email-masked]>
Date: Fri, 26 Apr 2013 13:40:03 +0200

> set it to something like 8 hours?

AFAICT, this is controlled by the PHP variable session.cache_expire,
which is set to 3 hours already. are you really editing the same page
longer than 3 hours and thus getting kicked off, or may there be
something else at play?

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

---

From: Paul Waring <[email-masked]>
Date: Fri, 26 Apr 2013 13:00:56 +0100

> longer than 3 hours and thus getting kicked off, or may there be

Despite its name, session.cache_expire does not affect the expiry of 
sessions or the cookies associated with them.

As far as I can tell from examining the headers, it looks like an expiry 
date/time is set for the login cookie, but then it is never updated. If 
this is the case, then eventually the expiry date will pass and the 
browser will delete the cookie, even if you have been regularly 
accessing the wiki.

Another possibility is that the cronjob which auto-removes session files 
(assuming files are being used) is set to the default of 24 minutes - 
which will remove your session after that time regardless of what the 
cookie's expiry date is set to.

-- 
Paul Waring
http://www.pwaring.com

---

From: Magnus Hagander <[email-masked]>
Date: Fri, 26 Apr 2013 14:06:03 +0200

> sessions or the cookies associated with them.

I was just looking at the mediawiki wiki at
http://www.mediawiki.org/wiki/Manual_talk:Configuration_settings which
seem to says it does :S

But reading it again, it seems there is a second one, the gc one.

> date/time is set for the login cookie, but then it is never updated. If this
> is the case, then eventually the expiry date will pass and the browser will
> delete the cookie, even if you have been regularly accessing the wiki.
>
> (assuming files are being used) is set to the default of 24 minutes - which
> will remove your session after that time regardless of what the cookie's
> expiry date is set to.

We do have session.gc_maxlifetime set to 1440 which is the 24 minutes
you're referring to? So maybe this is the parameter we need to
(drastically) increase?

---

From: Paul Waring <[email-masked]>
Date: Fri, 26 Apr 2013 13:21:24 +0100

> you're referring to? So maybe this is the parameter we need to

Assuming session data is being stored in files (you can check that with 
session.save_handler), then you might want to increase 
session.gc_maxlifetime.

The cleanup cronjob runs at 9 and 39 minutes past the hour by default, 
so a session file might be deleted 24-54 minutes since it was last modified.

-- 
Paul Waring
http://www.pwaring.com

---

From: Josh Berkus <[email-masked]>
Date: Fri, 26 Apr 2013 09:57:20 -0700

> longer than 3 hours and thus getting kicked off, or may there be

You already seem to be on the trail of this, but the defacto timeout is
definitely somewhere between 10min and 1 hour, and far less than 3 hours.

Paul's diagnosis would be consistent with the random-seeming kickoffs
I'm getting.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

---

From: Bruce Momjian <[email-masked]>
Date: Fri, 26 Apr 2013 16:37:27 -0400

> Paul's diagnosis would be consistent with the random-seeming kickoffs

Yes, I have found it annoying too and complained.  The big problem is
you are sitting on a wiki page, e.g. TODO, and when you hit the 'edit'
button, you can't because you were logged out.  This is just
user-hostile.

-- 
  Bruce Momjian  <[email-masked]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

---

From: Alvaro Herrera <[email-masked]>
Date: Fri, 26 Apr 2013 18:11:31 -0300

> button, you can't because you were logged out.  This is just

I'm used to sites keeping me logged in for, say, a week, so I don't have
to worry about it at all ... well, except my bank and such, of course.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

---

From: Stefan Kaltenbrunner <[email-masked]>
Date: Sat, 27 Apr 2013 08:39:24 +0200

On 04/26/2013 02:21 PM, Paul Waring wrote:
>>> which

interesting hint - thanks.

I have now increased the relevant timeouts to 6h - lets see how that goes..

Stefan

---

From: "Joshua D. Drake" <[email-masked]>
Date: Fri, 26 Apr 2013 23:55:20 -0700

> I have now increased the relevant timeouts to 6h - lets see how that goes..

FTR, I don't think we should autologout people or at least it should be 
set to something like 7D.

JD

---

From: Stefan Kaltenbrunner <[email-masked]>
Date: Sat, 27 Apr 2013 11:10:43 +0200

> set to something like 7D.

well from a security perspective it is usually advisable to keep session
lifetimes as short as possible, I agree that the current setup was way
to aggressive, but 6h already results in a 6-15x increase of what we had
before. We can always adjust upwards if we people are really working 6h+
on an article but lets see first if this change really fixes the issue
berkus complained about.

Stefan

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 27 Apr 2013 10:09:14 -0400

> on an article but lets see first if this change really fixes the issue

This is a wiki, not a banking website.  We need to use security that is
appropriate for what we are guarding.  We could just prevent edits and
it would be even more secure.  ;-)

I would like 7 days, myself.

---

From: Magnus Hagander <[email-masked]>
Date: Sat, 27 Apr 2013 17:24:51 +0200

> I would like 7 days, myself.

Note that this is not 7 days since you logged in. It's 7 days since
you last did something. And as long as you don't stop working, you
never get logged out ;)

---

From: "Joshua D. Drake" <[email-masked]>
Date: Sat, 27 Apr 2013 09:27:13 -0700

> I would like 7 days, myself.

Yep, I mean really, it is a wiki.

JD

-- 
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, Postgres-XC
@cmdpromptinc - 509-416-6579

---

From: Stefan Kaltenbrunner <[email-masked]>
Date: Sat, 27 Apr 2013 19:01:34 +0200

> you last did something. And as long as you don't stop working, you

and from looking at the average time between changes and the overall
changerate of any given site I don't really see how people people will
realistically hit the 6h limit. Anyhow if somebody wants to change this
to a larger limit I wont object, but 7 days seems mighty excessive...

Stefan

---

From: Josh Berkus <[email-masked]>
Date: Sat, 27 Apr 2013 10:50:50 -0700

> to a larger limit I wont object, but 7 days seems mighty excessive...

I'm fine with 6 hours, myself.  Especially since whatever used to
prevent me from caching my login creds got fixed/changed; logging in is
just clicking a link.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

---

From: Bruce Momjian <[email-masked]>
Date: Thu, 2 May 2013 20:40:45 -0400

> Yep, I mean really, it is a wiki.

OK, please make it 7 days.  I keep the wiki tab open on my browser and
having to log in every day is a pain.  Now, if you want me to stop using
the wiki, I am happy to do that.

---

From: Bruce Momjian <[email-masked]>
Date: Thu, 2 May 2013 20:41:53 -0400

> to a larger limit I wont object, but 7 days seems mighty excessive...

The problem is not having it timeout while you are using the wiki, it is
having it open and then having to re-login every day to do something. 
Please make it 7 days.

---

From: Magnus Hagander <[email-masked]>
Date: Fri, 3 May 2013 10:19:09 +0200

> the wiki, I am happy to do that.

Really, Bruce?

---

From: Bruce Momjian <[email-masked]>
Date: Fri, 3 May 2013 09:23:45 -0400

> > the wiki, I am happy to do that.

Yes, really.  I am not saying I will stop using the wiki, but it
certainly would be nice if I didn't have to use the wiki because others
used it more.  And the more cumbersome with wiki is to use, the more I
would like to avoid using it --- that's just natural.  I would think we
would have a setup to encourage people to use the wiki more by making it
easier to use.

I moved to the wiki so others could update the TODO list, but history
shows that I am still making the majority of the edits:

	https://wiki.postgresql.org/index.php?title=Todo&action=history

I do appreciate others making changes, but some of them are added
without discussion, so they need to be reviewed.  However, I don't
always get email when someone edits because of some logic that only
emails me the first time, unless I go to the site, though I have the
TODO list tab always open --- I never understood that.

There are other oddities, like many of the "Contents" links not working
(e.g. "Montoring"), and broken output when links contain '=', so I added
a cron job on my machine to check for them.

I asked about this timeout issue over a year ago, and was told no one
knew the cause.  Now that the cause was found, I am told that the
administrators want to set a timeout that is less than any other
non-commerce website I visit because of security.  To me that reflects a
distorted view of usability vs security, and all for a wiki site.

So if someone responsible wants to work on the TODO list, go ahead, it
is all there ready for you.  Odds are, I will never even see
notifications of your changes anyway.  :-(

Administrators say they increased the timeout 10x and need feedback if
it needs to be increased further?  Do you need me to notice that every
day I have to hit the 'edit' button, realize my session has timed out,
then hit the login button and try again.  It happened this morning ---
is that sufficient?  I have no idea.  Do these cookies control anything
but the wiki?  I assume not because 20 minutes was the MediaWiki default.

So, in summary, there are all these things on the wiki that don't work,
but I am having to fight to get something we can fix to a reasonable
default, and at a certain point, you just give up and find a way to do
it yourself, like maybe an auto-login javascript widget for the wiki.
(No, I have not written one, _yet_.  ;-) )

---

From: "Joshua D. Drake" <[email-masked]>
Date: Fri, 03 May 2013 08:55:53 -0700

> would have a setup to encourage people to use the wiki more by making it

As CVE as so eloquently pointed out, removing barriers to using the Wiki 
is a good idea. I like that when I decide to open Gmail it is just 
there, working. If I spent a lot of time on the wiki, I would expect it 
to work the same way. I don't want to log in every time, it isn't my bank.

Sincerely,

JD

---

From: Bruce Momjian <[email-masked]>
Date: Fri, 3 May 2013 18:16:32 -0400

On Fri, May  3, 2013 at 08:55:53AM -0700, Joshua D. Drake wrote:
> As CVE as so eloquently pointed out, removing barriers to using the
> Wiki is a good idea. I like that when I decide to open Gmail it is
> just there, working. If I spent a lot of time on the wiki, I would
> expect it to work the same way. I don't want to log in every time,
> it isn't my bank.

OK, having Googled "CVE" after seeing the above and failing, it took me
three hours to realize it is a joke related to PGDay NYC and stands for
Chief Village Elder.  LOL

---

From: Stefan Kaltenbrunner <[email-masked]>
Date: Sat, 04 May 2013 15:14:03 +0200

> would have a setup to encourage people to use the wiki more by making it

the huge success of MW as a basis for the likes of wikipedia does show
that it seems to be at least somewhat usable...

> TODO list tab always open --- I never understood that.

well - the idea is that people do not get spammed if somebody does a
large amount of edits, the fact that you "always have the page open in a
tab" does not help there because that means you are not actually doing
an http-request to the page so mw will never notice you are actually
having it open (http is basically stateless).
The current behaviour makes a lot of sense for the general usecase
because this would actually cause a mail storm if say a bot does a ton
of edits (and we have spammers abusing our wiki going through the
actually signing up for a community account and abusing our wiki for
link-backtrack spam, so this is not a theoretical point).

> a cron job on my machine to check for them.

again this a MW thing - it would be useful for somebody doing the
research if this is fixed in a different version or if there is another
way around it.

> distorted view of usability vs security, and all for a wiki site.

sure it is "only" a wiki - but given we do also maintain more or less
official stuff there it needs to keep a certain reputation. your
specific usecase of always having a particular page open is rather
unique in the general sense and it is not and was never optimized from
both a MW and also a infrastructure pov.
Also - as far as I see we have never gotten feedback if the recent
change to a larger timeout actually changed anything at all?

> but the wiki?  I assume not because 20 minutes was the MediaWiki default.

the ~20min is not a MW default, it is one from debian about cleaning up
session data (again a protection machanism, http is stateless and you
don't get a "user logged off" thingy in general so we need to remove
session data in some interval to not end up with millions of session files).
And yes as said above - we have speculated only so far on what exactly
the session timeout mechanics are and if the settings we are currently
dealing with actually control what people complain about - I'm still not
sure if you are saying it does or not?

> it yourself, like maybe an auto-login javascript widget for the wiki.

you do realise that the "Administrators" are mostly concerned about
running the platform in a scalable, secure and reliable way?
We are definitly not experts on every single piece of software from an
application PoV.
Most of the current complaints are either software issues (which we can
only support so much) or stuff that comes from the very specific
usecases that are different from what 95% of the people usually do (ie
editing articles for hours and hours in one go instead of multiple
smaller edits and keeping browers windows open for days on a specific
article).
Keep in mind that most of those defaults were choosen by people (package
maintainers, upstream developers,..) that know this stuff likely better
than any of us, so it is imho valid from a sysadmin pov to investigate
on why we need something different.

Stefan

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 4 May 2013 10:05:18 -0400

> that it seems to be at least somewhat usable...

It is certainly usable, but if it can be made more user-friendly, why
not?  The number of bugs I have reported isn't ideal, for sure.

> having it open (http is basically stateless).

Well, I start my browser daily probably, but that doesn't seem to help.

> link-backtrack spam, so this is not a theoretical point).

I decided to look into this again and I see my preferences aren't set
for me to get emails for changes on my watch list:

	E-mail me when a page on my watchlist is changed

I am not sure of the value of a watch list if you don't get email
notifications.  If I try to enable that and save, I get a failure:

	There was either an authentication database error or you are not
	allowed to update your external account.

I am not sure when that setting was changed, but I certainly didn't do
it.  I bet that is why I don't get wiki change notifications.  Does
anyone else get notifications?

Also, it seems not getting email notifications is the default, because
if I press "Restore all default settings", it say it is saved and the
email is unclicked:

	https://wiki.postgresql.org/index.php?title=Special:Preferences&success

> research if this is fixed in a different version or if there is another

I don't even understand why it isn't working.  Here is TOAST and Montoring:

  <li class="toclevel-1"><a href="#TOAST"><span class="tocnumber">23</span> <span class="toctext">TOAST</span></a></li>
  <li class="toclevel-1"><a href="#Monitoring"><span class="tocnumber">24</span> <span class="toctext">Monitoring</span></a></li>

Here are the anchors:

  <a name="TOAST" id="TOAST"></a>
  <a name="Monitoring" id="Monitoring"></a>

TOAST link works, Monitoring does not.  Perhaps the HTML is mangled and
Firefox is buggy.

> change to a larger timeout actually changed anything at all?

Yes, I can't tell as my usecase is unusual.

> sure if you are saying it does or not?

I have no idea.

> on why we need something different.

Agreed.

---

From: Stefan Kaltenbrunner <[email-masked]>
Date: Sat, 04 May 2013 19:44:20 +0200

> not?  The number of bugs I have reported isn't ideal, for sure.

true - the question is "are the MW people aware?" or maybe "is it
something that in a newer version is fixed?"

[...]
> 	allowed to update your external account.

hmm thanks for the report - that seems to be a (fairly) recently
introduced buglet in our custom authentication backend, it should
however not have resulted in any lost functionality just the above error
message. Should be fixed now anyway.

> anyone else get notifications?

I do ;)

> 	https://wiki.postgresql.org/index.php?title=Special:Preferences&success

the "notfiy watchlist" feature is off by default in MW.

> TOAST link works, Monitoring does not.  Perhaps the HTML is mangled and

it is broken for me as well - I have no idea why though...

[..]

>> sure if you are saying it does or not?

hmm not sure I get that - if you restart your browser daily how are the
session cookies even get preserved, or do you use one of these "restore
session" features?

Stefan

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 4 May 2013 14:08:54 -0400

> message. Should be fixed now anyway.

OK, I was now able to add email notification for watch list changes. 
Let's see if I get any email when someone modifies something.  It might
take a few weeks before I would know.

> > anyone else get notifications?

Oh, that's interesting.  Did you have those buttons checked in your
preferences?  I did not.

> the "notfiy watchlist" feature is off by default in MW.

OK.

> session cookies even get preserved, or do you use one of these "restore

Uh, well, I have the TODO list as one of my default startup tabs.  Most
websites can still use old cookies on a browser restart, e.g. Gmail,
Slashdot.

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 4 May 2013 14:12:31 -0400

> websites can still use old cookies on a browser restart, e.g. Gmail,

I just checked and you are right that a browser restart automatically
logs me out.  I guess the code just doens't assume someone will be
sitting on a wiki page for hours/days.

---

From: Stefan Kaltenbrunner <[email-masked]>
Date: Sat, 04 May 2013 20:19:38 +0200

> take a few weeks before I would know.

hmm weird - afaiks the error message should have been cosmetic only, are
you saying that it seems to have actually prevented the notifications?

> Oh, that's interesting.  Did you have those buttons checked in your

yeah i had them (but I'm pretty sure I had manually checked them)

> websites can still use old cookies on a browser restart, e.g. Gmail,

hmm pretty sure that browsers are supposed to clear session cookies if
they are restarted otherwise you will create bad security issues.
Consider logging in to a some site with personal information, close your
browser hand over your laptop to somebody in the family for a quick
browsing session and he will automatically log in to whatever site you
been at before...

Stefan

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 4 May 2013 14:24:19 -0400

> you saying that it seems to have actually prevented the notifications?

Oh, it certainly prevented me from modifying my preferences, but it
certainly works now.

> yeah i had them (but I'm pretty sure I had manually checked them)

OK.  That explains it then.

> browsing session and he will automatically log in to whatever site you

Well, if I just go to gmail.com, it certainly knows I am bmomjian.  If I
go to slashdot.org, it knows I am bmomjian too.  I have to explicitly
log out if I want be logged out.

---

From: Greg Stark <[email-masked]>
Date: Sat, 4 May 2013 20:51:23 +0100

> browsing session and he will automatically log in to whatever site you

What is this "close your browser"? Are you sure you know when you
close your browser? What about background tasks that might keep the
browser process running even with no windows? And just because you
want Gmail open why does that mean you want to keep credentials for
Facebook and Amazon loaded? Or does it happen when you close the
window? What if there were other windows or if some other site had an
iframe on the web site you're trying to close that you didn't even
know about? When do you "close your browser" on your phone?

Now that the web is more of an application platform each application
needs to think about when it wants the credentials or other local data
it uses to expire and arrange for it to happen as desired. Depending
on a concept like "close the browser" means not really knowing when it
will happen.

-- 
greg

---

From: Stefan Kaltenbrunner <[email-masked]>
Date: Sat, 04 May 2013 22:23:14 +0200

> log out if I want be logged out.

erm - I guess those are using persistent (tracking) cookies(as in you
clicked on "keep me signed in" at one time) vs classic session cookies,
are you proposing we should impose persistent cookies on our users?

Stefan

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 4 May 2013 17:43:36 -0400

> are you proposing we should impose persistent cookies on our users?

I find the use of the word "impose" curious.  How do such cookies
"impose"?  Is it storage imposition?  Security imposition?  From a user
perspective, it seems like a feature, not an imposition.

One nice thing our site does is when you click "login", it logs you in
without requiring me to actually see or type the username/password.  I
have no idea how we do that, so I suspect there must be some cookie
activity.

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 7 May 2013 10:47:06 -0400

> take a few weeks before I would know.

I am now getting email notifications of TODO changes.  :-)

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 14 May 2013 23:25:09 -0400

> having it open and then having to re-login every day to do something. 

Where are we on increasing this timeout?

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 15 May 2013 07:24:15 -0400

> Where are we on increasing this timeout?

On other weird thing is that when your session login times out, there is
no indication on the screen, and when you click on something like
"edit", instead of being presented with a login request, you get a
read-only copy of the page.  With other sites, I would normally get a
request to login for such an action.  

I am not sure if this is the wiki software default, or caused by the way
our wiki login is hooked to our community login credentials.  This is
another aspect of the login timeout that makes the site unfriendly ---
you are never really sure if an action is going to work, or you are
going to get a read-only copy, and the read-only copy isn't obvious
until you start trying to type something or notice the text is more dim
than usual.

---

From: Josh Berkus <[email-masked]>
Date: Wed, 15 May 2013 10:55:27 -0700

WWW,

First off, whatever tuning you did didn't work.  I'm still getting
logged out, after considerably less than 6 hours.  I'd say about 20min,
in fact.

Second, people should be aware of a bug where if you have an ' in your
URL, you can't use the login on that page (try logging in from the
What's New page).  It's a mediawiki bug.

> request to login for such an action.  

This is a mediawiki design flaw.  i.e. it's a bad design choice upstream.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

---

From: Josh Berkus <[email-masked]>
Date: Wed, 15 May 2013 10:58:10 -0700

> logged out, after considerably less than 6 hours.  I'd say about 20min,

Wait, no.  That's not the issue.  The real issue is somewhat stranger.

1. log into wiki.postgresql.org.

2. in a new browser tab/window, follow this link:

http://wiki.postgresql.org/wiki/PgCon_2013_Developer_Meeting

... you will find yourself not logged in on that tab, even though you
are on another tab.

3. now click this link:

https://wiki.postgresql.org/wiki/PgCon_2013_Developer_Meeting

... now you're logged in. WTF? Apparently login state is only detected
for HTTPS links?

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

---

From: Magnus Hagander <[email-masked]>
Date: Wed, 15 May 2013 20:00:53 +0200

> ... now you're logged in. WTF? Apparently login state is only detected

Yes, the login cookie is set to be sent only over https, for security reasons.

For our other websites, this will be automatically detected and you
get redirected to https (try going to your account page on the main
website with http for example), but at last I don't know of a way to
do that in mediawiki.

Should be easy enough to see - check your mediawiki cookies, and
you'll see they are enabled for https only.

---

From: Paul Waring <[email-masked]>
Date: Wed, 15 May 2013 19:44:10 +0100

> you'll see they are enabled for https only.

That's not quite accurate - there are three cookies set by *.postgresql.org:

postgresql.org - csrftoken (expires a year after being set)
postgresql.org - sessionid (expires two weeks after being set)
wiki.postgresql.org - wikidb_session (expires on browser close)

Only the sessionid cookie requires a https connection, the other cookies 
will be sent if a request is made over a http connection.

If all wiki connections should be over https - including guests - then 
that can be accomplished via a simple rule in the Apache virtual host 
configuration. If only logged in users require https then you'd need 
either a plugin to handle this, or register a 'hook' which is a small 
piece of PHP which is run before Mediawiki displays a page and forces a 
redirect if the request was not made over https *and* the wikidb_session 
cookie is set.

-- 
Paul Waring
http://www.pwaring.com

---

From: Magnus Hagander <[email-masked]>
Date: Wed, 15 May 2013 20:47:19 +0200

> postgresql.org - csrftoken (expires a year after being set)

That one is, I believe, not actually part of that site. It's leaking
over fromthe main website.

> will be sent if a request is made over a http connection.

Yes. But the interesting cookies here are wikidbUserID and wikidbUserName.

> If all wiki connections should be over https - including guests - then that
> can be accomplished via a simple rule in the Apache virtual host
> configuration. If only logged in users require https then you'd need either

Assumign we used apache. But yes, that's a trivial configuration in
any webserver. That is not the current intention, though we might want
to revisit that in the future.

> a plugin to handle this, or register a 'hook' which is a small piece of PHP
> which is run before Mediawiki displays a page and forces a redirect if the
> request was not made over https *and* the wikidb_session cookie is set.

Do you know if there's a readymade plugin that supports this?

---

From: Paul Waring <[email-masked]>
Date: Wed, 15 May 2013 20:12:46 +0100

> Do you know if there's a readymade plugin that supports this?

There does not appear to be one - the two which did exist have been 
deprecated and not updated since 2009, and in any case they only forced 
https on pages such as the login.

-- 
Paul Waring
http://www.pwaring.com