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]> 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]. > 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.
