On Tue, Mar 11, 2014 at 4:31 PM, Luca Garulli <[email protected]> wrote:
> You should pass authentication header only the first time, then OrientDB > returns a session id. If you pass that session id, you're good. > > Thant's good ! It should be like that only. Few more related questions: 1. Any specific way to send session id (OSESSIONID) ? Do we need to send that in header (what config in header) or as parameter (for get) or as data (for post) ? 2. What is the session life by default ? 3. Can we configure life of session ? For instance lets say infinite, till user log out explicitly. Regards, Gaurav > 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 a topic in the > Google Groups "OrientDB" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/orient-database/BXDuzJ3AHUc/unsubscribe. > To unsubscribe from this group and all its topics, 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.
