Hi Luke, Chris,
On Fri, Jul 1, 2011 at 5:34 AM, Luke <[email protected]> wrote:
> On Thu, 30 Jun 2011, Chris Travers wrote:
>
> On Thu, Jun 30, 2011 at 3:21 PM, Erik Huelsmann <[email protected]> wrote:
>>
>>> How does using one and the same user, let's call her Sammy, work with
>>> user
>>> management for multiple companies?
>>>
>>
>> So this is a bit of an issue which must be further discussed in terms
>> of default behavior and documented.
>>
>> * What happens if I do that and the user already exists in the psql
>>> cluster
>>> (because she's in another database)?
>>>
>>
>> Right now by default there is a check to keep this from happening. I
>> expect to create a function which is a drop-in replacement without the
>> check enabled.....
>>
>
> Which will presumably warn that the double creation is happening, but allow
> it anyway?
>
> Really, though, it should be configurable whether it is allowable or
> rejected.
>
>
> The basic concern is what happens where these need to be separated?
>> My general sense at the moment is that the situations where this could
>> happen accidently (and thus give users accidental access to other
>> companies' data in hosted environments) are bad enough that we
>> shouldn't remove the check by default.
>>
>> On the other side, maybe hosting companies should be expected to put
>> more effort into it than the average user... So maybe we should
>> reverse this.
>>
>
> I would agree with reversing it. The case for hosting companies is going
> to be more rare than the case of normal users, and the case for normal users
> wanting a single user for multiple companies seems like something that will
> happen a lot.
>
>
I hold the same opinion; when I would be running a hosting company, I'd be
doing one of two things:
1. Make LSMB prefix all users with their associated company name (i.e. make
the actual database logins: <company>__<user>)
2. To support multiple companies for one client, I'd create a more general
prefix-generation routine, something like <customernumber>__<user>
> There should still be a warning, but it should be permitted by default, or
> enabled with relative ease.
>
> Perhaps we need a document for hosting providers, that explains these
> concerns (among others that we know of), and what should be done to mitigate
> them (among others, of course).
>
Well, anyone starting LSMB hosting should really study what they're doing
before doing it. I mean, obviously, you're playing with someones most
trusted data. It's not like you should go monkeying about with that.
> Disclaimer: I have been known to run up to ten active company databases at
> once, and having to use different users is most annoying. So I have a
> vested interest in this being supported.
>
Which only supports the case that for "normal" users, it's not an uncommon
case.
Bye,
Erik.
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
