[Xerte-dev] Re: Using Two Authentication Methods

Ron Mitchell ronm at mitchellmedia.co.uk
Thu May 16 15:15:38 BST 2013


Thinking out loud but this should work...

 

create a new very basic php page which the static login people should go to
e.g. static.php

this would be unique to your install and therefore not broken by upgrades

 

set a session variable in there e.g. set static to true and then redirect to
index.php

 

edit auth_config.php and check for that session and switch to static
authentication if that session is set

 

So the only page you would have to protect from upgrades is auth_config.php
which to be honest if you're upgrading regularly you need to do anyway.

 

This is theory but I think should work.

 

HTH

Ron

 

From: xerte-dev-bounces at lists.nottingham.ac.uk
[mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Julian Tenney
Sent: 16 May 2013 14:28
To: For Xerte technical developers (xerte-dev at lists.nottingham.ac.uk)
Subject: [Xerte-dev] Using Two Authentication Methods

 

Hi,

 

I need a bit of help from someone who knows the authentication stuff better
than me:

 

We have some cases where, in the past, we've kept a few usernames /
passwords in the auth code, and have checked against those before checking
against LDAP. There are some collective efforts here where content is passed
to a central admin account - one that has static authentication. Lots of
people create content in their own accounts, and then pass it to the admin
account when it is finished, and that sets up a lot of content for feeds,
etc. Downstream, a website reads the folder feeds and displays the content.

 

When we upgraded, we lost this capability. Now that user can't login.

 

So I need to be able to either hardcode a username / password in somewhere
(I know, I don't like it either) or have two auth methods, static, and then
LDAP (or the other way around) if the first one fails, and I need a solution
that won't break in the future when we upgrade again, because this is a real
pain.

 

What's the best solution?

 

Thanks,

 

Julian





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nottingham.ac.uk/pipermail/xerte-dev/attachments/20130516/b9bb63df/attachment.html>


More information about the Xerte-dev mailing list