> On Mar 25, 2015, at 3:39 AM, Janusz Majnert <j.majn...@samsung.com> wrote:
>
> OK. This makes no sense for me.
>
> So you propose that the server does simple translation of SQL from url to
> actual query, but you don't see any security issue with this?
> If on the other hand you're proposing that the server validates the sql sent
> by client, then the simplest (and proven) solution is to have an API entry
> point that does the query that your client wants without any sql in the urls.
HI Janusz,
The proposal here makes no assumption about the server architecture and data
that’s exposed by the server using the client’s SQL syntax. The server is
still responsible for securing its data, as always.
A server that receives a command like:
SELECT first_name, last_name FROM users;
May parse that and translate that into something usable.
But, if it receives an SQL command like:
DROP TABLE students;
A simple server framework might not even be able to parse it and just ignores
it, while a more advanced server framework might try to authenticate and verify
it. Meanwhile, for a local SQL database, like on a game on your mobile device,
it might very well delete the table. But for a remote server, anything could
happen, depending on the server’s design.
I’m not sure why people think they would connect to a remote SQL server with
full privileges? I mean, they could if they wanted, but that most likely won’t
happen. There would likely be an app server in between the client and the
database, like how things are now.
Right now, if an app server gets this request:
http://api.mywebsite.com/get_article?id=1234
It’ll happily oblige.
But if it receives an:
http://api.mywebsite.com/delete_article?id=1234
The server still has to authenticate the request. Server-side app designers
still have to implement their security checks, like they would in a framework
like Django:
from django.contrib.auth import authenticate
user = authenticate(username='john', password='secret')
if user is not None:
# the password verified for the user
if user.is_active:
print("User is valid, active and authenticated")
else:
print("The password is valid, but the account has been
disabled!")
else:
# the authentication system was unable to verify the username
and password
print("The username and password were incorrect.”)
A server-side app designer still has to write this kind of code. This proposal
doesn’t remove that requirement.
This proposal means to put the idea of using SQL syntax to get/set data. As we
build on it, there would be an ORM that we could standardize so that clients
could use this SQL syntax.
This basically somewhat standardizes the syntax for structured remote API data
access.
-bobby
---
Bobby Mozumder
Editor-in-Chief
FutureClaw Magazine
mozum...@futureclaw.com <mailto:mozum...@futureclaw.com>
+1-240-745-5287
www.futureclaw.com <http://www.futureclaw.com/>
twitter.com/futureclaw <https://www.twitter.com/futureclaw>
www.linkedin.com/in/mozumder <http://www.linkedin.com/in/mozumder>
