WebAdmin plugin - user activation/deactivation

Are you having problems with using or developing a plugin? Let me know here.
Post Reply
Posts: 6
Joined: Mon Feb 22, 2016 9:30 pm

WebAdmin plugin - user activation/deactivation

Post by bilbolodz » Fri Feb 09, 2018 12:58 pm

Hello, I'm looking a 'easy way" (curl method preferred) to activate/deactivate particular user in VRS. I need to enable/disable users according state of their receivers. I've already implemented a script which detects sending/not sending data by user but now I've to block/unblock account. Now I'm using external apache proxy with authentication (VRS auth disabled) but it could be good idea to use build in authentication. My first try was updating records in VRS sqlite database it's not working (user records are overwritten by VRS using "in memory state") .

Users can be enabled/disabled by WebAdmin plugin but I don't know how to do it from my script not from web browser. I've tried to find a way using web console but it looks that problem is more complicated than accessing some URL with "username=USERNAME&disabled=1" :( Any ideas how to do it?

Posts: 2249
Joined: Fri Feb 17, 2012 3:20 am

Re: WebAdmin plugin - user activation/deactivation

Post by agw » Sun Feb 18, 2018 11:21 pm

The new OWIN stuff that's coming with version 3 includes Microsoft's Web API 2, which makes it straight-forward to implement REST interfaces. The plan is to expose a bunch of new API calls on the web admin plugin to let you do things like the call you describe.

If you can't wait for that then you can use the existing web admin calls, but there is a fair lump of work involved. Also that work will be redundant once version 3 gets released (eventually!), the calls you'd be making will be going away in favour of the Web API 2 versions.

However, if you want to get something going now then this is how you would do it.

For background - in the normal GUI each screen is made up of two objects - a presenter which handles reading and writing the configuration & doing the validation, and a view which presents the configuration and validation to the user and lets them enter changes. The presenter used by the normal WinForms views is the same presenter that the web admin plugin uses for its HTML views.

Unfortunately the presenters were written before the Web Admin plugin was written and some of them, particularly the settings presenter, hold some variables internally. Those presenters need to have new instances created and tied to each instance of the view that's rendered by the web admin plugin. The upshot is that when you fetch Settings.html from the server you get a random GUID ID generated for the view instance, and that GUID ID tells the web admin plugin which presenter you're using. You can see the GUID if you look towards the end of Settings.html:

Code: Select all

window.pageHandler = new VRS.WebAdmin.Settings.PageHandler('2ed4b2d4-411d-45f6-b65e-0fd035e3220a');
In there the 23bd....3200a bit is the view ID and you'll get a new value every time you fetch Settings.html. You need that ID when you load and save the settings via the web admin plugin. So you would need to:

1. Fetch Settings.html
2. Search for the line above and extract the GUID from the HTML.
3. Call Settings/GetState passing the view ID as a query string parameter called __ViewID (two underscores) - so in the example above it'd be Settings/GetState?__ViewId=2ed4b2d4-411d-45f6-b65e-0fd035e3220a
4. That returns a JSON object with all of the settings in it, including the user settings. Within the object that's returned is an object called Configuration that holds the settings.
5. Change Configuration as required.
6. Pass the Configuration object from the JSON as the body in a POST to Settings/RaiseSaveClicked. The form in the body has two fields: configurationModel, which is the Configuration object from the GetState call, and __ViewId, which is your view ID. The body has a content type of application/x-www-form-urlencoded; charset=UTF-8 and the configurationModel field is a JSON string that has been URL encoded.

That won't return whether it worked or failed. Applying your settings changes could involve restarting the server, which would normally break the conversation with the server before you get the response, so instead the save is queued and the response gives you a deferred job ID. You need to poll the server to find out if it worked. To do that you take the JobId from the response to RaiseSaveClicked and periodically do a GET to Settings/GetDeferredResponse passing the JobId as a query string parameter along with the ViewID. So if you got this JSON back in the RaiseSaveClicked:

Code: Select all

Then you would repeatedly do GETs on Settings/GetDeferredResponse?jobId=84b0aa4b-efd3-408a-b065-b9213568141d&__ViewId=2ed4b2d4-411d-45f6-b65e-0fd035e3220a. I think the screens do them once a second.

If the save has not completed yet then you get the same response as you got from RaiseSaveClicked - you get the JobId repeated back to you. If an exception was thrown then Exception gets filled in. Once it's finished then you get a Response that has the full Configuration object in it:

Code: Select all

{"Exception":null,"Response":{"CurrentUserName":null,"Configuration":{"DataVersion":98 --- 8< ---
The web admin plugin can detect when someone else has changed settings between you fetching and saving them. It will return a message in Exception saying that the configuration was changed elsewhere.

View IDs will expire if you don't send a message to the server within a short period of time. In your case that probably won't matter but if you need to keep the ViewID alive then you can do a GET on Settings/BrowserHeartbeat?__ViewId=<whatever>.

Post Reply