I too feel that exposing whole DB over REST is inviting hackers to your app; esp for public / cloud apps. There should be some configuration switch using which we can enable / disable the whole REST functionality. Ideal will be blocking default REST exposure of DB and giving access to server only through server defined function (even login). Everything on REST should be accessible through REST call to functions like *http://<<host>>:<<port>>/function/<<db>>/<<function name>>/ <<arguments>>*. In this case all security and cross-checking can be done by developer in server side defined functions.
Back to main topic, I noted that OrientDB returns OSESSIONID on successful connect. What is the purpose of OSESSIONID if OrientDB does not use it in subsequent HTTP / REST calls to apply access control. Regards, Gauarv On Tuesday, March 11, 2014 2:49:44 PM UTC+5:30, Milen Dyankov wrote: > > Well, I agree with Domenico - this (passing username and password on each > request) is a security issue. In fact at most of my customers such approach > would never pass thier security audits. > > Note, I'm talking about the general approach not the OrientDB case. It is > a whole different story whether it's a good idea to have the database > availabe via REST in a network where the traffic can be sniffed. I > personally prefer to have App <-> DB communication isolated in dedicated > network when possible. > > But back to the issue - the statlesness of REST has nothing to do with > this. There are number of ways to provide more secure stateless > authentication (tokens beeing the simplest one) then sending passwords with > each request. > > Just my 2 cents. > > > On Tue, Mar 11, 2014 at 10:00 AM, Mateusz Dymczyk > <[email protected]<javascript:> > > wrote: > >> I'm not talking about statelessness of HTTP but about basic REST >> principles. OrientDB is trying to expose a REST interface, which by >> definition is stateless. The kind of statefulness you are talking about >> also has a lot of problems (what if you have a load balancer between your >> clients and distributed DB services? you need to manage that which usually >> means much more work than plain authentication/authorization). About >> security you can as well say that someone can find out your session ID the >> only benefit of it is that it might sooner or later expire. >> >> Mateusz >> >> >> On Tuesday, March 11, 2014 5:32:04 PM UTC+9, Dom54 wrote: >>> >>> Hi, >>> yes HTTP is stateless, but this doesn't mean we can't had session's >>> concept like almost all web applications do. >>> Sending credentials with every request is a bad idea from an operational >>> and security point of view. >>> From an operational point of view this implies that the server has to >>> execute the authnetication process for each request, which implies addind >>> overhead to each request has compared to simply check is a session ID >>> exists and is still valid. >>> From a security point of view resending credentials with each request >>> increases the risk that the credentials are caught by others (even using >>> TLS/SSL; see the patch Apple was urged to provide to fix a bug in its >>> implementation of the TLS/SSL stack!), unless you take specific measures to >>> protect them (which increase the processing overhead). >>> Ciao >>> Domenico >>> >>> ------------------------------ >>> >>> On 11 Mar 2014 at 1:10, Mateusz Dymczyk wrote: >>> >>> REST by definition is stateless so what you are asking for isn't REST. >>> What's bad with sending credentials with every request? >>> >>> Mateusz >>> >>> On Tuesday, March 11, 2014 4:19:26 PM UTC+9, Gaurav Dhiman wrote: >>> I noted that the way OrientDB authenticate user for every HTTP access >>> is by expecting username:password encoded in base64 for every HTTP call. >>> Isn't that a bad idea. >>> >>> I think, username:password should only be expected once at the time of >>> login (HTTP connect call). Once connect is successful, OrientDB should >>> return session ID and in consecutive call to ORientDB server that session >>> ID should be sent in place of username:password combination. Using >>> sessionID OrientDB should be able to fetch current logged-in user and and >>> its details at server end to perform specific actions. >>> >>> Can we achieve above in OrientDB (for HTTP REST calls) ? >>> >>> Regards, >>> Gaurav >>> -- >>> >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "OrientDB" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to *[email protected]*. >>> For more options, visit >>> *https://groups.google.com/d/optout*<https://groups.google.com/d/optout> >>> . >>> >> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "OrientDB" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > http://about.me/milen > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
