[Koha-devel] "IP address has changed. Please log in again"

[Michael Hafen]

Please don't force HTTPS in the software.  I'll explain why I'm making that
request here.

First, it's easy to force HTTPS in the apache config for the vhosts, I've
done this.  It's a simple matter of a redirect on the port 80 vhost pointed
at the https vhost.  This is where certificates would likely be configured
anyway, so I think this is a reasonable way to do it.

I've been playing with setting up a web server farm, with a fail-over pair
of reverse-proxy servers as the front.  As a performance measure
communication between the proxies and the worker nodes is done over plain
http (because I trust my LAN enough for that).  I ran into a problem with
my tests though where a web app forced https in the software, it produced a
redirect loop, because the worker would respond with a http meta redirect
to the https port but the web browser was already using that port.  Luckly
I would turn off that feature in the software.

I understand that forcing https in the software is a good security
measure.  I'm just asking that it be controlled by a system preference, or
be made an optional section in the apache config file in consideration of
those who would like to avoid the overhead added by https.

Thanks for your consideration.


On Thu, May 30, 2013 at 12:18 PM, Galen Charlton <gmc at esilibrary.com> wrote:

> Hi,
>
> On Wed, May 29, 2013 at 3:58 PM, Robin Sheat <robin at catalyst.net.nz>
> wrote:
> > Standard session cookies combined with running over HTTPS is really the
> > only way. It comes down to threat modelling really: is session hijacking
> > something that you feel you care about? (It's perfectly reasonable to
> > say either yes, no, or only on the staff client, depending on your
> > circumstances.)
>
> I'd personally be happy with requiring SSL for the staff interface and
> the OPAC throughout on the basis that patron information is sensitive
> enough to demand that level of care.
>
> However, because of the general support issues that would arise around
> SSL certs, I suspect that Koha jumping on the HTTPS Everywhere
> bandwagon will likely have to remain a recommended practice rather
> than a requirement or installation default.
>
> > To make it a bit more secure we could use a different session for the
> > staff client vs. the OPAC. At the moment we use the same for both, so
> > someone capturing a session cookie from a staff member logged into the
> > OPAC can use that to access the staff client.
>
> I think this is a good idea.
>
> Regards,
>
> Galen
> --
> Galen Charlton
> Manager of Implementation
> Equinox Software, Inc. / The Open Source Experts
> email:  gmc at esilibrary.com
> direct: +1 770-709-5581
> cell:   +1 404-984-4366
> skype:  gmcharlt
> web:    http://www.esilibrary.com/
> Supporting Koha and Evergreen: http://koha-community.org &
> http://evergreen-ils.org
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20130530/cdc477d1/attachment.html>