[turba] Restricting Database Access
Claus Heiko Niesen
cniesen@gmx.net
Thu, 06 Sep 2001 17:40:43 -0500
I don't really like the idea of two different turba installation. I'd
rather hack search.php and advanced.php and add a little if statement like
this:
/* Build the directory sources select widget. */
$source_options = '';
foreach ($cfgSources as $key => $entry) {
if (($key != 'restricted_database') || ($imp['user'] ==
'the_special_user')) {
$selection = (isset($source) && $source == $key) ? ' selected' : '';
$source_options .= "<option value=\"$key\"$selection >";
$source_options .= $entry['title'] . "</option>\n";
}
}
Thanks for your help Jan
Claus
Hint: The user name is stored in $imp['user']. However, this might only
be true since IMP is the application that handles user verification for
me. Somebody might want to correct me on this.
At 05:04 PM 09/06/2001, you wrote:
>We currently have no acls implemented.
>
>The only thing I could think of is to install turba in two different
>directories with different authentication themes.
>
>Jan.
>
>Zitat von Claus Heiko Niesen <cniesen@gmx.net>:
>
> > I added a foreign table that contains e-mail addresses to the source.php
> > with success. Currently anybody that has access to IMP can utilize the
> > database. I would like to restrict that to a selected few people. The
> > database itself doesn't contain any information regarding who is allowed to
> > access it and who isn't. The perfect thing would be to display the
> > database as a choice to only the people that have access to it. I was
> > wondering if there is some mechanism in place.
> >
> > Claus
> >
> > Hint: To combine a first and last name field to be used in turba use the
> > following mapping in source.php:
> > 'name' => 'first_name || \' \' || last_name'
> >
> >
> > --
> > Turba mailing list: http://horde.org/turba/
> > Frequently Asked Questions: http://horde.org/faq/
> > To unsubscribe, mail: turba-unsubscribe@lists.horde.org
> >
> >
>
>
>::::::::::::::::::::::::::::::::::::::::
>AMMMa AG - discover your knowledge
>:::::::::::::::::::::::::::
>Detmolder Str. 25-33 :: D-33604 Bielefeld
>fon +49.521.96878-0 :: fax +49.521.96878-20
>http://www.ammma.de
>::::::::::::::::::::::::::::::::::::::::::::::
>
>--
>Turba mailing list: http://horde.org/turba/
>Frequently Asked Questions: http://horde.org/faq/
>To unsubscribe, mail: turba-unsubscribe@lists.horde.org
>From chuck@horde.org Date: Thu, 6 Sep 2001 18:46:35 -0400
Return-Path: <chuck@horde.org>
Mailing-List: contact turba-help@lists.horde.org; run by ezmlm
Delivered-To: mailing list turba@lists.horde.org
Received: (qmail 58682 invoked from network); 6 Sep 2001 22:47:08 -0000
Received: from h00104bc60b3c.ne.mediaone.net (HELO marina.horde.org) (24.91.198.7)
by horde.org with SMTP; 6 Sep 2001 22:47:08 -0000
Received: by marina.horde.org (Postfix, from userid 33)
id 27EBC3A05; Thu, 6 Sep 2001 18:46:36 -0400 (EDT)
Received: from 192.168.0.124 ( [192.168.0.124])
as user chuck@localhost by marina.horde.org with HTTP;
Thu, 6 Sep 2001 18:46:35 -0400
Message-ID: <999816395.3b97fccbe9009@marina.horde.org>
Date: Thu, 6 Sep 2001 18:46:35 -0400
From: Chuck Hagenbuch <chuck@horde.org>
To: turba@lists.horde.org
References: <5.1.0.14.2.20010906165426.00afe640@pop.gmx.net> <5.1.0.14.2.20010906165426.00afe640@pop.gmx.net> <5.1.0.14.2.20010906171530.00ad8328@pop.gmx.net>
In-Reply-To: <5.1.0.14.2.20010906171530.00ad8328@pop.gmx.net>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 2.3.7-cvs
Subject: Re: [turba] Restricting Database Access
Quoting Claus Heiko Niesen <cniesen@gmx.net>:
> Hint: The user name is stored in $imp['user']. However, this might only
> be true since IMP is the application that handles user verification for
> me. Somebody might want to correct me on this.
You should _never_ refer to $imp outside of IMP. It's not guaranteed to be
there, it's not guaranteed to be sane, and it's the kind of tight coupling that
Horde 1.3 is designed to avoid.
-chuck
--
Charles Hagenbuch, <chuck@horde.org>
Some fallen angels have their good reasons.