You should pass authentication header only the first time, then OrientDB returns a session id. If you pass that session id, you're good.
Lvc@ On 11 March 2014 17:51, Gaurav Dhiman <[email protected]> wrote: > 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]>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. > -- --- 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.
