Hi, 1) Look at Studio: put the OSESSIONID in the request's header. 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]> 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]. >>>> 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. > -- --- 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.
