| Subject | Re: [firebird-support] Re: RE: How would Firebird prevent users thrasing database |
|---|---|
| Author | Tim Ledgerwood |
| Post date | 2004-04-06T14:29:57Z |
At 04:10 PM 06/04/2004, you wrote:
in real life. In real life, your single biggest client comes to you and
says "we want to be able to access your files in order to do x, y or z".
(In our case "because our chartered accountants have written a web based
MIS system that will draw data from your files".) So now you have a choice.
Either you tell your biggest client to go to hell (and make sure that it's
a multi - billion $ international corporate while you're doing it, like
ours is), or you have to write a whole bunch of work arounds and extra code
to allow them to do that.
Or else you get a huge "opportunity" - a possible sale - which falls
through because their IT guys are as sharp as you are, and think that this
idea of you holding them to ransom isn't actually a very good idea.
Or else the engineering manager and the support manager tell the board that
it is extremely difficult for any of the 50 or so field engineers to
support the program in the field, because of all the extra security you
have put in place to make sure that no - one except you understands what
you've done.
Or else your product target market becomes more and more limited because
your application can't speak the standard Structured Query Language, and
nobody exept you can fix it when it's broken.
Where did you learn your programming style? Microsoft? :-)
In my experience, the kind of security spoken about is far more trouble
than it is worth, and limits your options severely. Hell, IMHO, even
password / user level security is only worth all the effort in very
specific cases - and then NEVER to "protect" my own code - like in
Financial or Asset management systems, where you want to see who has done what.
Regards
Tim
[Non-text portions of this message have been removed]
>-----BEGIN PGP SIGNED MESSAGE-----Not only that (which I agree with), but I'll tell you how it works
>Hash: SHA1
>
>He's saying the security you are talking about is only skin deep. The
>security you talk about is file based and is therefore fairly easily
>worked around. Therefore, for people who are really trying to get at
>your database, its not security at all. Unless, its a really feable
>attempt. And if thats the case you probably don't have much to worry
>about anyways.
>
>Edward
in real life. In real life, your single biggest client comes to you and
says "we want to be able to access your files in order to do x, y or z".
(In our case "because our chartered accountants have written a web based
MIS system that will draw data from your files".) So now you have a choice.
Either you tell your biggest client to go to hell (and make sure that it's
a multi - billion $ international corporate while you're doing it, like
ours is), or you have to write a whole bunch of work arounds and extra code
to allow them to do that.
Or else you get a huge "opportunity" - a possible sale - which falls
through because their IT guys are as sharp as you are, and think that this
idea of you holding them to ransom isn't actually a very good idea.
Or else the engineering manager and the support manager tell the board that
it is extremely difficult for any of the 50 or so field engineers to
support the program in the field, because of all the extra security you
have put in place to make sure that no - one except you understands what
you've done.
Or else your product target market becomes more and more limited because
your application can't speak the standard Structured Query Language, and
nobody exept you can fix it when it's broken.
Where did you learn your programming style? Microsoft? :-)
In my experience, the kind of security spoken about is far more trouble
than it is worth, and limits your options severely. Hell, IMHO, even
password / user level security is only worth all the effort in very
specific cases - and then NEVER to "protect" my own code - like in
Financial or Asset management systems, where you want to see who has done what.
Regards
Tim
[Non-text portions of this message have been removed]