Web gui in root 6.32.00 : how to handle multiple windows?

Dear ROOT developers,

I’m trying to re-learn how to use ROOT web gui in root 6.32.00.
Used it before (with rood 6.28.xx) but something has changed.

Here comes the description of the problem I’m facing

  1. I have ROOT 6.32.00 build with +root7+webgui , the relevant part of .rootrc looks as follows:
Browser.Name: ROOT::RWebBrowserImp
WebGui.HttpPortMin: 8800
WebGui.HttpPortMax: 9800
WebGui.HttpLoopback: yes

I’m running on Alma Linux 9, the web browser used is firefox coming with the AL9 installation

  1. on a client host, I have an ssh tunnel forwarding its local :8877 to the server( mu2edaq09) :8877. After starting ROOT I can display a histogram in a remote web browser window.
mu2etrk@mu2edaq09:~/test_stand/pasha_028>root.exe --web=server:8877
   ------------------------------------------------------------------
  | Welcome to ROOT 6.32.00                        https://root.cern |
  | (c) 1995-2024, The ROOT Team; conception: R. Brun, F. Rademakers |
  | Built for linuxx8664gcc on Jul 03 2024, 03:23:57                 |
  | From heads/v6-32-patches@tags/v6-32-00                           |
  | With g++ (Spack GCC) 13.1.0                                      |
  | Try '.help'/'.?', '.demo', '.license', '.credits', '.quit'/'.q'  |
   ------------------------------------------------------------------

root [0] auto c1 = new TCanvas("c1","c1",800,600)
Info in <THttpEngine::Create>: Starting HTTP server on port 127.0.0.1:8877
New web window: http://localhost:8877/win1/?key=a282702b-10538519-3abed48e-81bfea70-eb6d4a90-834ef734-48b5b56d-d3b0ffd0#59780d07-e85ccb4d-82aba6b0-486d315d-60c45071-06775814-987128b5-cebfb951
(TCanvas *) 0x2de0990
root [1] auto h1 = new TH1F("h1","h1",10,0,1)
(TH1F *) 0x4de4e70
root [2] h1->Draw()
  1. I can also open another canvas, direct the browser to the suggested URL (…win2/) and draw a histogram in another browser tab:

root [3] auto c2 = new TCanvas(“c2”,“c2”,800,600)
New web window: http://localhost:8877/win2/?key=93ce02ea-e335ccbd-7e0ab998-77e1a9e4-9715f017-97b48022-422e26d3-762f2cf0#59780d07-e85ccb4d-82aba6b0-486d315d-60c45071-06775814-987128b5-cebfb951
(TCanvas *) 0x40874b0
root [4] auto h2 = new TH1F(“h2”,“h2”,10,0,1)
(TH1F *) 0x536b190
root [5] h2->Draw()

However, a refresh of the first, left on the attached image, tab (win1) results in an empty tab:

I can open another canvas and draw it in the third browser tab -

but a refresh of the second tab leaves it empty, with no way to recover the histogram ‘h2’ previously displayed in it:

now come questions:

  1. it looks that the access key is a necessary attribute - dropping it on the first access results in an empty browser window. The keys change from one session to another, How does a remote (say, monitoring) client know about the access key it is supposed to use ? In a root version I used before specifying the ‘?key=…’ was not needed

  2. what i observe is consistent with only one http connection being maintained by the server. How dow one maintain multiple active tabs with histograms displayed in them? - I remember there was a .rootrc parameter specifying , in some way, the max number of web connections, but can no longer find it. Perhaps this is related?

– many thanks. regards, Pasha

Hi Pasha,

Sorry to read ROOT did not work out of the box for you in this case. Thanks a lot for the complete report: it is useful to improve the webgraphics. I am adding in the loop @linev .

Cheers,
Danilo

Hi Pasha,

We increase default security settings for the http server used to display all kinds of web widgets.
URL which is required to connect with web widget is unique and can be used only once.
If many connections with the widget are required - new dedicated URLs have to be produced for every new connection.

In case of running ROOT with the argument --web=server:8877 widget URL printed in the terminal. To get new URL for the canvas just call c1->Show().

Regards,
Sergey

We increase default security settings for the http server used to display all kinds of web widgets.
URL which is required to connect with web widget is unique and can be used only once.
If many connections with the widget are required - new dedicated URLs have to be produced for every new connection.

Danilo, Sergey, thank you for your replies.

I understand the need in secure web connections and I also understand that a ROOT connection provides write access on a server side.

Few things still remain unclear:

  1. in the original posting, I reported that opening the second secure connection with a specified access key seemed to be closing the first connection, also secure, also opened with the specified access key. Is that the expected behavior?

  2. I’m currently living in the DAQ world, and we are relying on a ROOT-based monitoring DAQ program to produce multiple histograms/canvases and display them on the web.

[Remote] shifters have access only to the web browser, that plus a set of URLs is their only tool.
The shifters however need to have access to multiple canvases.

Could you describe what the shifters using root 6.32.00-based applications are supposed to do when when the DAQ monitoring restarts - how would they restore the web pages they were looking at 5 min ago when using the new security mode? According to Sergey, all URLs will change and I don’t see an easy solution. I’m sure though that the issue has been thought through.

  1. as many others, the Mu2e DAQ is running on a private network with all connections to it being kerberized ssh connections. In this case one doesn’t need additional application-level protections. Is there a way of turning them off and re-establishing the root 6.26-6.28 defaults ?

In case of running ROOT with the argument --web=server:8877 widget URL printed in the terminal. To get new URL for the canvas just call c1->Show().

  1. as far as I can tell, it prints nothing - see below. Perhaps I misinterpreted what he wrote?

mu2etrk@mu2edaq09:~/test_stand/pasha_028>root.exe -b --web=server:8877

| Welcome to ROOT 6.32.00 https://root.cern |
| (c) 1995-2024, The ROOT Team; conception: R. Brun, F. Rademakers |
| Built for linuxx8664gcc on Jul 03 2024, 03:23:57 |
| From heads/v6-32-patches@tags/v6-32-00 |
| With g++ (Spack GCC) 13.1.0 |

Try ‘.help’/‘.?’, ‘.demo’, ‘.license’, ‘.credits’, ‘.quit’/‘.q’

root [0] auto c2 = new TCanvas(“c2”,“c2”,800,600)
(TCanvas *) 0x2845750
root [1] c2->Show()
root [2]

  1. If I don’t specify ‘–web=’ parameter above, the canvas pops up in a window on the screen. The .rootrc settings are given in the original report and I’d expect them to be directing the canvas to the web by default. What am I missing ?

  2. finally, where can I find documentation explaining how to use the new interface ? perhaps, if I read it, I could find answers to many questions myself

– thanks, regards, Pasha

Hi,

I cannot reproduce such behavior. But one should clearly understand that simple refresh of web page does not work with ROOT web widgets. The only supported way to reload browser content is to use Ctrl-R keys combination. While this is the only possibility to correctly request new connection key.

If you are sure about security of your network you can disable authentication feature of ROOT web widgets, In such case simple url like http://server:8877/win1/ will work again and can be used as many times as necessary. But you can use it on your own risk:

WebGui.OnetimeKey: no

Please remove -b flag - for the moment it disables web server mode completely.
I will try to fix problem - while --web=server:xxxx was designed to work also in batch mode

This is still in my long todo list

Regards,
Sergey

Hi,

Addressing your questions I made several modifications in ROOT:

  1. Let correctly use web widgets in batch mode when server mode is configured
    root -b --web=server:port. Patch applied to master and 6.32 branch.

  2. Important configuration of connection keys usage is provided as ROOT method: RWebWindowsManager::SetUseConnectionKey(false);. Also in master and 6.32 branch.

  3. Improve reload functionality of web widgets (not only canvas). Together with Ctrl-R handler one also can use standard browser reload. This fix will be applied only in master branch.

Regards,
Sergey

Hi Sergey, [sorry I didn’t reply earlier - have an ongoing DAQ integration week, and that takes all the time and cuts the communication off] - thank you very much !

For both the work your’e doing and the time you take to answer questions.

– regards, Pasha