On Fri, Jul 1, 2011 at 5:34 AM, Luke <..hidden..>
On Thu, 30 Jun 2011, Chris Travers wrote:
On Thu, Jun 30, 2011 at 3:21 PM, Erik Huelsmann <..hidden..
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
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.
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.
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
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.