> > 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. >
The cookie should go back automatically from the browser. But you have to add it in (in a server specific way) if you write your own server that sits between your client and the db and its not a pass through. I'm writing a finatra server between a web front end and orientdb and other services. So I was trying to test my understanding of the security approach in orientdb using curl. > If we need to programatically place it before making HTTP / REST call, how > to do it ? > > In JS, you can set it in the headers by adding an ajax preFilter in jquery. > 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]> 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.
