Well, yes, the theory is nice, but I've come across a glitch. I guess this is why people asked for HTTP/S tunneling in Guacamole. In my case, I was using Apache in reverse proxy mode with modsecurity to be on the safe side, and all I needed to do was include custom public web links within guacamole-client. That worked fine until I was told by my organization that I could not do that. Everything has to go through just one platform, ie. Guacamole. So my only option is to try to use RemoteApps or drop support for it altogether.
In my earlier tests when I wrote to you the following RemoteApp call worked fine: firefox.exe -profile "C:\Firefox\profile" -private-window https://myURL I have userchrome.css in "C:\Firefox\profile\chrome", and it's content is: @namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul";); /* only needed once */ #openLocation, #CustomizeToolbarWindow, #toolbar-context-menu, #search-container, #personal-bookmarks, #menubar-items, #PanelUI-button { display:none!important; } #urlbar-container { visibility:hidden; } #tabbrowser-arrowscrollbox {pointer-events: none} toolbarbutton#scrollbutton-up, toolbarbutton#scrollbutton-down {pointer-events:auto} .tabbrowser-tab, #tabs-newtab-button, .tabs-newtab-button {pointer-events: auto} .new-tab-popup, .new-tab-popup > * {pointer-events: auto} /*container tabs - longpress*/ #menu_unsortedBookmarks { display: none !important; } #menu_mobileBookmarks { display: none !important; } #subscribeToPageMenuitem { display: none !important; } #subscribeToPageMenupopup { display: none !important; } #organizeBookmarksSeparator { display: none !important; } #bookmarksToolbarSeparator { display: none !important; } #bookmarksToolbarFolderMenu { display: none !important; } #bookmarksToolbarFolderMenu+menuseparator { display: none !important; } I enabled toolkit.legacyUserProfileCustomizations.stylesheets in about:config. For the sake of completeness I also disabled browser.newtabpage.enabled. That leaves the user with a browser that cannot be used to manually navigate to other sites, but if the site needs to open new tabs or if the user needs to go back in the browser's history, he/she can (unlike in kiosk mode). At some point though, after running the RemoteApp with at least 2 different users, the third started to behave oddly. The same call (firefox.exe -profile "C:\Firefox\profile" -private-window https://myURL) would apply my userchrome.css but would not open https://myURL. Instead, it would open the default Firefox "newtabpage" if browser.newtabpage.enabled was set to true. However, the following call would work fine (but without the custom userchrome.css): firefox.exe -private-window https://myURL So it made me think of some kind of permissions issue in "C:\Firefox\profile". Deleting everything in that dir and leaving just the chrome/ subdir fixed the problem. So I can either find out why the common profile dir is getting screwed up (I wish Firefox had an application error log), or deploy the chrome/userchrome.css into each user's profile, as you suggested (not sure how to properly do that yet). Maybe even a RemoteApp that runs a custom script which wipes out "C:\Firefox\profile" leaving only the chrome/ subdir before actually running firefox.exe with its arguments. Sounds very ugly, but it might work if the user running the process can actually delete the dir content. Thanks, Vieri --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
