Thanks Luca, for switch user example. I will raise a feature request to block default REST layer.
Regards, Gaurav On Jul 22, 2014 3:29 PM, "Luca Garulli" <[email protected]> wrote: > Hi Gaurav, > The idea to protect URL is cool, may you open a new issue? > > About change the current user: > > db.switchUser("writer", "mypassword"); > > Lvc@ > > > > On 22 July 2014 05:25, Gaurav Dhiman <[email protected]> wrote: > >> One more him to ask. >> >> You mentioned about creating www user and switching users in OrientDB >> function. How to do that ? How can we switch the user, what call to make ? >> Kindly share example code. >> >> Regards, >> Gaurav >> On Jul 22, 2014 8:53 AM, "Gaurav Dhiman" <[email protected]> wrote: >> >>> Hi Luca, >>> >>> Thanks for sharing workarounds but isn't there a better way to block >>> port and IPs at OrientDB level using its configuration ? I think this an be >>> added as functionality as many people would like to block the default REST >>> layer, only allowing access through function defined REST layer. It will be >>> good even if the functions an be marked as public (accessible over REST), >>> private (not accessible over REST, can only be called by other functions), >>> this is something which Wakanda provides. >>> >>> Regards, >>> Gaurav >>> On Jul 22, 2014 3:26 AM, "Luca Garulli" <[email protected]> wrote: >>> >>>> Hi Gaurav, >>>> Simon is right. you could also put Apache in form of OrientDB and use >>>> Apache rules to protect it. >>>> >>>> Another solution we adopted is to create a www user with no privilege, >>>> but executing functions. In your functions you can change user to writer or >>>> any other user with privilege to work against the database. >>>> >>>> >>>> Lvc@ >>>> >>>> >>>> >>>> On 21 July 2014 21:17, <[email protected]> wrote: >>>> >>>>> You should be able to block external access to the port via your >>>>> external firewall. >>>>> >>>>> Some options are: >>>>> >>>>> 1. If the server side functions are happening on the same server as >>>>> OrientDB, make sure that local server side connections happen via the >>>>> loopback address 127.0.0.1. >>>>> >>>>> 2. Another option: set up another LAN IP (ex: 192.168.0.22) for >>>>> internal access to the database via the REST API. Then set your firewall >>>>> to >>>>> block access from the other external IP address. >>>>> >>>>> 3. If you're restricted to 1 IP (ex: some cloud systems or VPS), you >>>>> have a few options. >>>>> One is, you can use a VPN for internal access. >>>>> >>>>> Another is, that you should still be able to create a whitelist of IPs >>>>> that can access the server on that port. >>>>> It depends on your OS and your firewall. >>>>> >>>>> >>>>> >>>>> >>>>> On Tuesday, March 18, 2014 2:18:43 PM UTC-4, Gaurav Dhiman wrote: >>>>>> >>>>>> Stefan, >>>>>> >>>>>> Thanks for response. >>>>>> I want to restrict default REST access but want to allow access >>>>>> through OrientDB server side functions, so blocking port will even block >>>>>> access to functions defined in OrientDB. >>>>>> >>>>>> Example: >>>>>> I want to block calls like >>>>>> http://<host>:<port>/document/<db>/5:3 >>>>>> http://<host>:<port>/cluster/<db>/demoClass >>>>>> >>>>>> Want to still have REST access to functions defined in OrientDB; call >>>>>> like: >>>>>> http://<host>:<port>/function/<db>/myFunction/arg1/arg2 >>>>>> >>>>>> >>>>>> Regards, >>>>>> Gaurav >>>>>> >>>>>> >>>>>> >>>>>> On Tuesday, March 18, 2014 11:17:02 PM UTC+5:30, >>>>>> [email protected] wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> You can block the port that OrientDB runs on. >>>>>>> You can either do this locally on the machine or limit access to the >>>>>>> machine if it's running on a sub-net. >>>>>>> >>>>>>> Regards, >>>>>>> -Stefán >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tuesday, 18 March 2014 12:52:51 UTC, Gaurav Dhiman wrote: >>>>>>>> >>>>>>>> Thanks Dexter for info. >>>>>>>> >>>>>>>> Building our REST layer is always an option but that does not block >>>>>>>> the direct DB access. If a user directly connects to DB on bare >>>>>>>> HTTP/REST, >>>>>>>> he will be able to access thins on it in his/her browser, I want to >>>>>>>> block >>>>>>>> that and only allow access through functions defined at OrientDB end. >>>>>>>> >>>>>>>> Thanks again for sharing your idea. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Gaurav >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sunday, March 16, 2014 12:19:33 AM UTC+5:30, Dexter Pratt wrote: >>>>>>>>> >>>>>>>>> In our case, we built our own REST server application to implement >>>>>>>>> our API - which is responsible for authentication, authorization, and >>>>>>>>> limits on queries - and it accesses OrientDB. >>>>>>>>> >>>>>>>>> It would be cool to do the whole thing in Orient, but our cases >>>>>>>>> are sufficiently complex that I think we need the separate REST server >>>>>>>>> layer. >>>>>>>>> >>>>>>>>> I'll be interested to see how far you can push this. >>>>>>>>> >>>>>>>>> - Dexter >>>>>>>>> >>>>>>>>> Dexter Pratt >>>>>>>>> Director, NDEx project >>>>>>>>> Ideker Lab UCSD / Cytoscape Consortium >>>>>>>>> [email protected] - [email protected] >>>>>>>>> www.ndexbio.org >>>>>>>>> >>>>>>>>> On Saturday, March 15, 2014 at 11:39 AM, Gaurav Dhiman wrote: >>>>>>>>> >>>>>>>>> Any suggestions on this? >>>>>>>>> How to block default HTTP/REST access to DB and only allow access >>>>>>>>> on HTTP/REST through server side functions ? >>>>>>>>> >>>>>>>>> Any suggestions will help a lot. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Gaurav >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thursday, March 13, 2014 8:55:14 PM UTC+5:30, Gaurav Dhiman >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I do not want the default HTTP/REST access open for anyone to look >>>>>>>>> into DB (even logged-in user). >>>>>>>>> I want to give access on HTTP/REST through server defined >>>>>>>>> functions only, all other REST access should not be allowed. >>>>>>>>> >>>>>>>>> How to achieve it ? >>>>>>>>> >>>>>>>>> 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. >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>> >>>>> --- >>>>> 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/7IJf5d_LcoI/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 a topic in the > Google Groups "OrientDB" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/orient-database/7IJf5d_LcoI/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.
