> I hope you are talking about server-side JavaScript solutions,
> because
> giving client-side JavaScript direct-access to your database sounds
> even
> worse :) Oktober was dubbed leaktober by an online IT magazine here
> in NL:
> every business day (and sometimes in the weekend) they exposed at
> least one
> (gaping) security hole in websites of companies, government etc. Most
> of
> these were basic SQL injection attacks; lets make sure we reduce the
> potential of that type of attacks, not increase the chance :)

No, I am talking about client-side JavaScript, but I do not think that
the approach itself is prone to security breaches more than any other
web-service. The SQL injection is easy to avoid - use prepared
statements and do not use EXECUTE STATEMENT in the prepared statements
and things will work fine. The permissions can be enforced on the
web-server level and on database level they are enforced by the database
server itself. The issue is to avoid using some technical user with
SYSDBA permissions and then to try to enforce the security rules
somewhere above the DB layer. This is solved by mapping real application
users to different roles on the database level.

In general, there is no difference between whether you create a generic
web service to read/write data from/into the table (or view) or you
create a web-service that translates calls into appropriate calls to the
database layer.

>> I have presented RESTful link between SmartClient/SmartGWT and
>> Firebird
>> on Firebird Conference in Bremen.
>
> Are the slides (or video) available somewhere?

Maybe IBExpert people have put them somewhere... I will send you the
slides per mail, I can send you also the code...

Roman