On Saturday, May 31, 2014 9:37:07 PM UTC+5:30, Lvc@ wrote: > > Hi, > 1) Look at Studio: put the OSESSIONID in the request's header. >
Do we need to place it or is it placed automatically by browser in subsequent server calls ? I have an understanding that it is placed automatically in all subsequent calls. If we need to programatically place it before making HTTP / REST call, how to do it ? This might be a reason that some of my HTTP / REST calls return 401 error. > 2) You could set the property "network.http.sessionExpireTimeout" that now > is 300 seconds (5 minutes). > > Lvc@ > > > > On 17 April 2014 15:25, Gaurav Dhiman <[email protected] <javascript:>> > wrote: > >> 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] <javascript:>. >>>>> 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] <javascript:>. >>>> 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] <javascript:>. >> 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.
