Once login is successful and we get OSESSIONID in cookie, do we need to sent that explicitly in subsequent HTTP calls or is that sent automatically by browser (being part of cookie). Asking so, as in subsequent HTTP calls I could not see the OSESSIONID in request header under chrome debugger. 1. If we need to send it explicitly, how to send it - What header to set ?
2. How can we set the session life to infinite? Session should not die unless user explicitly logs out. Regards, Gaurav On Tuesday, March 11, 2014 4:52:08 PM UTC+5:30, Gaurav Dhiman wrote: > > > > On Tue, Mar 11, 2014 at 4:31 PM, Luca Garulli 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 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 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.
