2 Replies Latest reply on Jul 7, 2014 3:48 AM by 25c49980-cb2e-4113-a5a7-2f0078c85330

    Rhoconnect API Access Levels


      We're just beginning to try to use RhoConnect Push to accomplish push sync on TC-55's.


      I've followed the examples and got the push to work (most of the time) and have started to bake calls to the Rhconnect API into our application (as it happens that is in PL/SQL).


      The issue I have is that I want the application to be able to lookup up users/devices and issue pingsl, but I don't want it to have access to reset the server, add or delete things.  I can't find documentation or examples on controlling what an api user can do, or in fact anything about having any other user that rhoadmin.  I don't really want to embed a username/password to a user that could issue a full reset within a database.


      Has anyone approached this in a different way, or has anyone figured out how to create new users and limit their use of the api?


      Many thanks



        • Re: Rhoconnect API Access Levels

          No, only the admin can do the things that you want to achieve. But, you don't need to supply the admin user/password to the app. You just need to use api_token with the API requests:

          For example:

          User Resource – GET users

          GET /rc/v1/users 

          List users registered with this RhoConnect application.

          users = RestClient.get( "#{server}/rc/v1/users", { 'X-RhoConnect-API-TOKEN' => @api_token } ).body 

          See the docs:


          Rhomobile | RhoConnect REST API

            • Re: Rhoconnect API Access Levels



              Thanks for the pointers.


              I needed to supply the username and password to get hold of the token with the /rc/v1/system/login call unless I store the API token elsewhere (and synchronise it with the master),


              The API and surrounding infrastructure seems a little underdeveloped to me - I think it's essential for the API to have varying levels of access (probably governed by dynamic tokens - rather than a single one held in a file) or it seems to me like it's exposing the whole system.


              This is especially highlighted when all I want to do is do a push sync - very application-ny, not very admin-ny.  But to do this, it feels like I need to expose the crown jewels so to speak.


              Other than automatically triggering on a model change or from within a source adapter method, is there another way of triggering the push sync?