search

Moonshine-IDE / Super.Human.Portal

Portal interface to show documentation for DominoVagrant and Super.Human.Installer
Other
0 stars 1 forks source link

Open Nomad links in same Window #53

Closed piotrzarzycki21 closed 4 months ago

piotrzarzycki21 commented 6 months ago

From HCL:

Greetings Justin and the Prominic team,

Thank you for meeting with us to discuss the Nomad team's progress regarding a number of issues. I have attached the slide deck shared in the 20220222 checkpoint meeting detailing the launch handler and link capturing feature experiments in Chrome and Nomad Web. Since we last spoke, the Chromium team has communicated that this experimental feature will not be available in Chrome release 123 due to issues they're seeing with the current implementation. We will continue to monitor and test their changes accordingly in order to improve the link handling experience in Nomad.

On slides 3-5, I've added a number of scenarios and the observed behaviors that an end user may experience. Each of these are under the condition that both the Chrome experiment and Nomad experiment flags are enabled.

We also discussed an alternative solution that may suit Prominic's needs by using service worker messaging to open links in an existing Nomad browser tab or PWA window. Slide 6 is an explanation of how Nomad Web is using this messaging API to trigger the opening of links in the main Nomad window if the browser has opened an intermediate secondary window. On slides 7-9, I have included an example web page, scopedlinks.html, that leverages that functionality by overriding the browser's default behavior of clicking on a link to use the navigator.serviceWorker.controller.postMessage() API instead. You may edit and test this file with links appropriate to your deployment. Paste this file in the nomad-files/ directory with the rest of the Nomad Web client files. This will ensure that the postMessage() calls are messaging Nomad's service worker. Note that this is not using launch handler or link capturing features. The experiments do not need to be Enabled to test this page.

Thank you for your time to continue to discuss these issues as we work toward a solution. Please feel free to reach out if you have any further questions.

scopedlinks.html.zip

Summary from @piotrzarzycki21

Here is the context of our short chat today. They provided example in html file, I have added that code to Super.Human.Portal in Browse My Server - select some application and click "Open in Nomad" their code will be executed. Lates build should have my changes. If you open Web Developer tools and go to file MediatorBrowseMyServer jump to method: onOpenNomadWeb - place there debugging break point and you will be able see that ServiceWorker is in pending state and controller is null.

I'm wondering based on their description below whether we need some special deployment for Super.Human.Portal to have it working. Maybe you will have some thoughts on that - if not let me know and I will respond to this email asking for assistance.

UPDATE: Branch: https://github.com/Moonshine-IDE/Super.Human.Portal/tree/features/issue_53_nomad_links

JoelProminic commented 6 months ago

This is experimental functionality, so I'd prefer to keep it in a branch so that it doesn't interfere with the 0.1.9 release (which I have been trying to return to).

piotrzarzycki21 commented 6 months ago

You are right! I'm sorry about that - I will revert my changes in master tomorrow.

JoelProminic commented 6 months ago

My test Domino+Nomad instances are in a bad state at the moment, so I may run out of time to test this today.

Were you able to get the example HTML file to work? By my understanding, the process is:

  1. Open Nomad once with the exp_link_capturing option: https://nomadweb.demo.startcloud.com/nomad/?exp_link_capturing=true
  2. Upload the HTML file to the Domino server (i.e. /local/notesdata/domino/html/scopedlinks.html)
  3. Open the test HTML file. Note that the subdomain is different: https://domino.demo.startcloud.com/scopedlinks.html
  4. Click on one of the links.

I originally tested with Chrome, but this failed with an error on step 1 (even when I enabled the suggested option). image

I got past this on Firefox, but it triggered the the "no serrvice worker registered" case.

My theory is that we would need to be on the same subdomain to properly trigger this. I'm looking for a way to confirm this.

piotrzarzycki21 commented 6 months ago

Were you able to get the example HTML file to work?

No I did not, I don't know how to upload stuff to server.

piotrzarzycki21 commented 6 months ago

I originally tested with Chrome, but this failed with an error on step 1 (even when I enabled the suggested option).

It means that your ServiceWorker is probably in the same state is mine - pending, nothing change, but in order to confirm that it would be good to look into console debugger of scopedlinks.html

piotrzarzycki21 commented 6 months ago

I have moved code in SHP to branch, you can grab build here

piotrzarzycki21 commented 6 months ago

I would like to respond them next week with our tests results. What if we need to be under same subdomain to trigger that - would it change significantly our SHP effort ?

JoelProminic commented 6 months ago

Were you able to get the example HTML file to work?

No I did not, I don't know how to upload stuff to server.

@piotrzarzycki21, I was talking with @rat-moonshine about deploying files for another project. Some options:

piotrzarzycki21 commented 6 months ago
  • Add it to the build directory for a Royale project and deploy it from Moonshine. The backend for this is generic, so we may make a generic Moonshine feature for this soon.

@JoelProminic I think I sort of did that. Because solution is implemented in Super.Human.Portal - I'm deploying this from Moonshine and it's on my server.

piotrzarzycki21 commented 6 months ago

I've tried this but I'm getting permission denied. I think I don't understand something here correctly:


piotrzarzycki@Piotrs-MacBook-Pro ~ % vagrant global-status
id       name                         provider   state    directory                                                                                       
----------------------------------------------------------------------------------------------------------------------------------------------------------
ec79cde  default                      virtualbox running  /Users/piotrzarzycki/Dev/machines                                                               
423cb4b  3785--mars.startcloud.com    virtualbox poweroff /Users/piotrzarzycki/Library/Application Support/SuperHumanInstallerDev/servers/demo-tasks/3785 
96031e2  2405--jupiter.startcloud.com virtualbox running  /Users/piotrzarzycki/Library/Application Support/SuperHumanInstallerDev/servers/demo-tasks/2405 

The above shows information about all known Vagrant environments
on this machine. This data is cached and may not be completely
up-to-date (use "vagrant global-status --prune" to prune invalid
entries). To interact with any of the machines, you can go to that
directory and run Vagrant, or you can use the ID directly with
Vagrant commands from any directory. For example:
"vagrant destroy 1a2b3c4d"
piotrzarzycki@Piotrs-MacBook-Pro ~ % vagrant scp /Users/piotrzarzycki/Dev/prominic/scopedlinks.html 96031e2:/local/notesdata/domino/html/scopedlinks.html
Warning: Permanently added '[127.0.0.1]:2222' (ED25519) to the list of known hosts.
scp: dest open "/local/notesdata/domino/html/scopedlinks.html": Permission denied
scp: failed to upload file /Users/piotrzarzycki/Dev/prominic/scopedlinks.html to /local/notesdata/domino/html/scopedlinks.html
piotrzarzycki@Piotrs-MacBook-Pro ~ % vagrant scp /Users/piotrzarzycki/Dev/prominic/scopedlinks.html 96031e2:/local/notesdata/domino/html/                
Warning: Permanently added '[127.0.0.1]:2222' (ED25519) to the list of known hosts.
scp: dest open "/local/notesdata/domino/html/scopedlinks.html": Permission denied
scp: failed to upload file /Users/piotrzarzycki/Dev/prominic/scopedlinks.html to /local/notesdata/domino/html/
piotrzarzycki@Piotrs-MacBook-Pro ~ %
rat-moonshine commented 6 months ago

Why don't you tried with sudo; until someone suggest you with sudo su?

piotrzarzycki21 commented 6 months ago

Why don't you tried with sudo; until someone suggest you with sudo su?

How do I do that ? Could you write step by step what should I do ? Should I open terminal from Super.Human.Installer and type what @JoelProminic propose ? What command ?

rat-moonshine commented 6 months ago

Looks like following command gives you permission trouble, try run this in following way:

sudo vagrant scp /Users/piotrzarzycki/Dev/prominic/scopedlinks.html 96031e2:/local/notesdata/domino/html/scopedlinks.html

You shall be ask to enter password.

piotrzarzycki21 commented 6 months ago

Looks like following command gives you permission trouble, try run this in following way:

sudo vagrant scp /Users/piotrzarzycki/Dev/prominic/scopedlinks.html 96031e2:/local/notesdata/domino/html/scopedlinks.html

You shall be ask to enter password.

@JoelProminic do you know what's the password to machines?

JoelProminic commented 6 months ago

I would do it like this:

# Use the button in SHI to open the Finder and Terminal window - I think this may bypass the password issue
# I would copy files to the home directory to avoid permissions issues
vagrant status      # to get the VM name
vagrant scp scopedlinks.html 4882--demo.STARTcloud.com:~/
# Then copy the file to the correct position and permissions
vagrant ssh
sudo cp scopedlinks.html /local/notesdata/domino/html/scopedlinks.html
sudo chown domino:domino /local/notesdata/domino/html/scopedlinks.html

Also note that for a single text file like this, you can do something like:

sudo so - domino
bash
cd domino/html
# replace vi with an editor you are comfortable with
vi scopedlinks.html
# Paste the contents of the file and save
JoelProminic commented 6 months ago

After more discussion with HCL, I found that we need to create the files in /opt/hcl/domino/notes/latest/linux/nomad-files. For example:

sudo su -
cd /opt/hcl/domino/notes/latest/linux/nomad-files
vi scopedlinks.html
# Open file at https://nomadweb.%server%/nomad/scopedlinks.html

To put Super.Human.Portal in the directory:

sudo su -
cd /opt/hcl/domino/notes/latest/linux/nomad-files/
ln -s /local/notesdata/domino/html/Super.Human.Portal Super.Human.Portal
# open with:  https://nomadweb.%server%/nomad/Super.Human.Portal/js-release/index.html

However, this would have problems with the agent URLs and CORS.

As an alternative, here is the haproxy solution we discussed with @MarkProminic today:

        ## Host ACL Definitions
        ...
                acl host_nomadweb             hdr(host)          -i nomadweb.demo.STARTcloud.com
                acl host_nomadweb_scopedlinks path_beg          /nomad/scopedlinks.html

        ...
        ## Application backends
        ...
                use_backend                     domino               if host_nomadweb host_nomadweb_scopedlinks
                use_backend                     nomadweb             if host_nomadweb
JoelProminic commented 6 months ago

From our discussion today, the plan is to have only a "nomadhelper" file inside nomad-files, and have that open the link:

  1. Click a link in Super.Human.Portal (under domino.%server%)
  2. Call https://nomadweb.%server%/nomad/nomadhelper.html?link=%link%
  3. nomadhelper.html opens the link with service worker
  4. nomadhelper.html closes the tab automatically after some time or confirming the action.
piotrzarzycki21 commented 6 months ago

@JoelProminic Issue which you have seen during meeting that only part of Super.Human.Portal was displayed - was real bug. Some of the links to used libraries - DevEpress were blocked for some reason. I changed them and now application is being displayed correctly.

This commit explains everything: https://github.com/Moonshine-IDE/Super.Human.Portal/commit/ab5397ee13391db1a7f4f41fc36725c67b41df31

piotrzarzycki21 commented 6 months ago

Deployed SHP to nomad folders of course won't work due to agents different domain. I just tried to put in nomad folders small js file nomadhelper.js. Loading this in Royale application ends up with cors issue:

The resource at “https://nomadweb.venus.startcloud.com/nomad/nomadhelper.js” was blocked due to its Cross-Origin-Resource-Policy header (or lack thereof). See https://developer.mozilla.org/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)# index.html

JoelProminic commented 6 months ago

Ah, I thought we already had spent time on a CORS workaround for this, but I think I'm confusing this with another issue

I think the solution for this is to add the CORS headers for nomadweb.%server% like this:

UPDATE: We received alternative CORS instructions from HCL. I have updated these for our servers:

sudo su - domino
bash
# edit nomad-config.yml with the command-line editor of your choice.  This file didn't exist already for me
# open the domino console
domino console
# run these commands
restart task nomad
close

Example of nomad-config.yml. Update the value like this: https://domino.%yourserver%

httpHeaders:
  Access-Control-Allow-Origin: https://domino.nomad-1010.nomadtest.com

UPDATE 2: To let this work, you'll need to comment out the CORS lines in /etc/haproxy/haproxy.conf

    ##BEGIN CORS
    #http-response set-header Access-Control-Allow-Origin "*"
    #http-response set-header Access-Control-Allow-Headers "Origin, X-Requested-With, Content-Type, Accept, Authorization, JSNLog-RequestId, activityId, applicationId, applicationUserId, channelId, senderId, sessionId"
    #http-response set-header Access-Control-Max-Age 3628800
    #http-response set-header Access-Control-Allow-Methods "*"
    ## END CORS

Commands:

    # Vagrant SSH
    sudo su -
    # Edit /etc/haproxy/haproxy.conf with the command-line editor of your choice
    # Verify the file
    haproxy -c -f /etc/haproxy/haproxy.cfg
    # Restart the service
    service haproxy restart

We should prirotize the above solution, but here is a (potentially incomplete solution from another task:

Run Vagrant SSH and Connect as root: sudo su -

Edit /etc/haproxy/haproxy.cfg with the command-line editor of your choice. Add these lines after backend nomadweb (note that you need to replace %yourserver%):

   http-after-response set-header Access-Control-Allow-Origin "https://domino.%yourserver%"
   http-after-response set-header Access-Control-Allow-Headers "*"
   http-after-response set-header Access-Control-Max-Age "31536000"

Update haproxy with the changes like this:

   # Verify the file
   haproxy -c -f /etc/haproxy/haproxy.cfg
   # Restart the service
   service haproxy restart

Then, open the HTML file you deployed (example: https://nomadweb.nomad-1010.nomadtest.com/nomad/scopedlinks.html) in a browser and check for the CORS headers.

You can then try this from Super.Human.Portal. Watch for the preflight issue I reported here - I'll update the above instructions if I work out a fix for this.

rat-moonshine commented 6 months ago

Without knowing much of the original issue here, but attracted to HAProxy.cfg file discussion - I went to comment-off the CORS lines in haproxy.cfg and test the MXHX application - but in browser console continuing to have an error:

POST https://restapi.prominic.domino.com/file/upload?rand=0.26464644545 net::ERR_CERT_AUTHORITY_INVALID

piotrzarzycki21 commented 6 months ago

UPDATE: We received alternative CORS instructions from HCL. I have updated these for our servers:

sudo su - domino
bash
# edit nomad-config.yml with the command-line editor of your choice.  This file didn't exist already for me
# open the domino console
domino console
# run these commands
restart task nomad
close

@JoelProminic going with that direction means I'm being asked for a password again and I still don't know what's the password to this domino instance.

Instead of going to domino user I'm trying follow your suggestion here

piotrzarzycki21 commented 6 months ago

Example of nomad-config.yml. Update the value like this: https://domino.%yourserver%

httpHeaders:
  Access-Control-Allow-Origin: https://domino.nomad-1010.nomadtest.com

By going with suggestion above do I create/modify nomad-config.yml under following location /local/notesdata/nomad-config.yml ?

JoelProminic commented 6 months ago

If I remember right su - domino requires a password, but sudo su - domino should not, at least if the current user is startcloud. I'm not sure if the domino user even has a real password defined - I have never needed to use this.

Yes, the file to create/update is /local/notesdata/nomad-config.yml. /local/notesdata/ is the home directory for the domino user, but in retrospect I should have used the absolute path.

JoelProminic commented 6 months ago

We ended up needing a fix for preflight for this issue as well. I added some instructions for this here.

However, we are still getting an error (ns_error_dom_corp_failed) when trying to load the nomadweb file as a JavaScript library.

UPDATE: I got some documentation for this policy from Firefox. This is a related policy called CORP (there is also CORB). To resolve this, we need to change Cross-Origin-Resource-Policy. I found that this was set to same-origin by default, and updating it in nomad-config.yml did not change this header.

I ended up fixing this in /etc/haproxy/haproxy.cfg. Add this line to backend nomadweb and restart the service

        http-after-response set-header Cross-Origin-Resource-Policy "same-site"

With this change, I was able to load nomadhelper.js. UPDATE 2: I needed to change Console.log to console.log, and then the debug message worked. You can find this code in the Firefox debugger if needed.

piotrzarzycki21 commented 6 months ago

I think we should take step back from our investigation. After some discussion with Adrian we are thinking that we need to run nomadhelper.js from server not from client. All our previous attempts (downloading with fetch, load javascript function, requesting trough XMLHttpRequest, dynamically importing) resulted in the code being called in the client not from the server.

We think we need to force Nomad to run nomadhelper.js as a part of the server.

We think we should respond to Daniel with fillowing message:

Pseudo code:

function openLink(req, res) => {
  if (req.url '/openLink') {
    const hrefUrl = new URL(req.link);
    if (navigator?.serviceWorker?.controller) {
      navigator.serviceWorker.controller.postMessage({
        type: 'openNotesUri',
        payload: {
          notesUri: decodeURIComponent(
            hrefUrl.hash.substring(
              hrefUrl.hash.indexOf(HASH_PREFIX) + HASH_PREFIX.length
            ),
          ),
        },
      });
    } else {
      console.error('no service worker registered');
    }

    res.writeHead(200, { 'Content-Type': 'text/plain' });
    res.end('some');
  }

Do you agree with this appraoch ?

JoelProminic commented 6 months ago

Here were the solutions proposed by @JustinProminic:

1) My main suggestion was to try to use a GET request on the shim file to tell it what to do and avoid CORS.

2) The next idea is to just put ALL of Super.Human.Portal under the nomad URL if ew have to with redirects like what Mark showed last week. This should be possible by using HAProxy and the rewrite rules if we have everything under S.H.P. matching a URL such as /SHP/index.html Then you can make SHP load off of nomadweb and work, in theory, from the same base URL.

3) A 3rd idea I have is to put a frameset around the SHP so that part of the page is SHP and part of it is the frame that contains loadjavascript.as and then you are able to call loadjavascript.as from the GET parameter and still avoid CORS.

Ok but 2 is actually the least favorite option. 1 or 3 would be better. But 2 is worth a try.

We have been working towards option 1 over the last few days, but when we were working on this yesterday we switched to trying to load the file from Nomad as a library, and then making a call using this. Unfortunately, I think this will probably still run as domino. - did you finish a test for this?

For 1, we would want to make a call to an HTML file on nomadweb.. This HTML file should contain the JavaScript code from the HCL example, as well as JavasScript code to read the query-string parameter and call the method to open the link. However, I don't think this file will be executed you just read the URL inside Royale - I think this would just return the raw HTML/JavaScript instead. Is there another way to evaluate this HTML in the local browser window?

I think 3 is promising. This would use the same HTML file as 1, but it would be opened in a "hidden" iframe instead. The file would then execute in that iframe. Note that there may be additional headers required to allow nomad to appear in iframes.

I'm not sure your proposed solution makes sense. This JavaScript needs to run on the client side in order to detect the local service working and update the local tab. Even if we have the Nomad server evaluates the GET request for us, it will still need a local environment to run. We could use iframes like 3, but then this just sounds like an unnecessary complication for 3.

piotrzarzycki21 commented 6 months ago

We ended up needing a fix for preflight for this issue as well. I added some instructions for this here.

However, we are still getting an error (ns_error_dom_corp_failed) when trying to load the nomadweb file as a JavaScript library.

UPDATE: I got some documentation for this policy from Firefox. This is a related policy called CORP (there is also CORB). To resolve this, we need to change Cross-Origin-Resource-Policy. I found that this was set to same-origin by default, and updating it in nomad-config.yml did not change this header.

I ended up fixing this in /etc/haproxy/haproxy.cfg. Add this line to backend nomadweb and restart the service

        http-after-response set-header Cross-Origin-Resource-Policy "same-site"

With this change, I was able to load nomadhelper.js. UPDATE 2: I needed to change Console.log to console.log, and then the debug message worked. You can find this code in the Firefox debugger if needed.

I'm sorry for missing this yesterday. Yes this resolves issue with CORS on my sight. I'm starting to play with idea of loading html website in our app and run nomad Service Worker code.

piotrzarzycki21 commented 6 months ago

@JoelProminic Something has started to work! I went trough deploying nomadhelper.html and loading it into our application. I've decided instead using iFrame to use JQuery.load function. As you can see in code url to nomadhelper i hardcoded - I'm not sure how we should provide that url to our application - if you wanted to test it on your end with different deployment you need to change url in CommandLaunchNomadLink and build Super.Human.Portal yourself.

piotrzarzycki21 commented 6 months ago

Functionality is working for now only i Browse My Server -> select application and use button Open in Nomad. Of course you will have to first copy nomadhelper.html

sudo cp /local/notesdata/domino/html/Super.Human.Portal_Royale/js-debug/resources/nomadhelper.html /opt/hcl/domino/notes/latest/linux/nomad-files

piotrzarzycki21 commented 6 months ago

@JoelProminic It looks like yesterday I was too optimistic with above solution - it turns out it didn't work. I've been spending with @Aszusz whole day on trying different approaches. We ended up using iFrame and this is working. I have pushed my code.

Here is what we had to do:

  1. In /local/notesdata/nomad-config.yml you have to add

X-Frame-Options: ALLOW-FROM https://domino.venus.startcloud.com

Once we added that we gain working window.onload in nomadhelper.html, but we have started to experience in console log following error in Firefox 124.0.2 (64-bit)

Invalid X-Frame-Options header was found when loading “https://nomadweb.venus.startcloud.com/nomad/nomadhelper.html?link=https%3A%2F%2Fnomadweb.venus.startcloud.com%2Fnomad%2F%23%2Fnotes%3A%2F%2Fvenus.startcloud.com%2FSuperHumanPortal.nsf”: “invalid” is not a valid directive. nomadhelper.html

Despite above error we had access to nomad ServiceWorker.

  1. If you wanted to use your custom server url you can change it here

  2. This part is still relevant https://github.com/Moonshine-IDE/Super.Human.Portal/issues/53#issuecomment-2037403402

Please grab latest build and try to test.

JoelProminic commented 6 months ago

Okay, I'll try this when I have a chance. I had some trouble with the testing yesterday, but I ran into some problem (probably not all related to the above change).

One problem that wasted a bunch of my time was that Nomad was very slow for me. Have you been noticing similar problems on your test VM? I'm worried that the haproxy or Nomad configuration changes could have had side-effects on the server performance, but I haven't been able to track down the problem yet.

piotrzarzycki21 commented 6 months ago

One problem that wasted a bunch of my time was that Nomad was very slow for me. Have you been noticing similar problems on your test VM?

Nope I'm not experiencing slowliness in that matter. Does version of Nomad have anything with that maybe ? I'm using 1.0.10.

piotrzarzycki21 commented 6 months ago

Invalid X-Frame-Options header was found when loading “https://nomadweb.venus.startcloud.com/nomad/nomadhelper.html?link=https%3A%2F%2Fnomadweb.venus.startcloud.com%2Fnomad%2F%23%2Fnotes%3A%2F%2Fvenus.startcloud.com%2FSuperHumanPortal.nsf”: “invalid” is not a valid directive. nomadhelper.html

I forgot to mention that this error do not appear in Brave browser which is my main browser - it's based on Chromium.

JoelProminic commented 6 months ago

I was able to resolve the slow response by restarting the browser (macOS Firefox). I'm not sure why it got into a bad state, but I noticed that I didn't have the same problem when testing with wget/curl or a different browser.

While testing, I am seeing this error on the console:

Invalid X-Frame-Options header was found when loading “https://nomadweb.nomad-1010.nomadtest.com/nomad/nomadhelper.html?link=https%3A%2F%2Fnomad.dmytro.cloud%3A9443%2Fnomad%2F%23%2Fnotes%3A%2F%2Fnomad-1010.nomadtest.com%2Fnames.nsf”: “invalid” is not a valid directive. nomadhelper.html

However, the database is still opening in the Nomad tab with the above error, so it doesn't seem to be a blocker.

Doing some research, I see that ALLOW_FROM is obsolete. I tried using this instead:

Content-Security-Policy: frame-ancestors https://domino.nomad-1010.nomadtest.com;

This worked, but I am still getting some warnings. I don't see x-frame-options set anywhere in nomad-config.yml or haproxy.cfg after my change.

Content-Security-Policy: Ignoring ‘x-frame-options’ because of ‘frame-ancestors’ directive.

Testing some more cases I see:

Test Case Behavior
Nomad is open and logged in Database opens in existing Nomad tab
Nomad is open but not logged in After user authenticates, database opens in existing Nomad tab
Nomad is not open Nothing happens

To support the last case, I think we should open the provided link in a new tab if the service worker is not defined. I did a quick test with this, but I ran into trouble with the popup blocker:

        } else {
            console.error('no service worker registered');
            window.open(link, '_blank'); // open in new tab unless configured otherwise by the browser
        }
piotrzarzycki21 commented 5 months ago

@JoelProminic I have added changes in other places where "Open in Nomad" button is displayed. It's in Installed Apps and Bookmarks. I have as well cleaned up a bit code of nomadhelper.html - deploy that one as well if you wanted to test latest build.

JoelProminic commented 5 months ago

Remaining steps:

JoelProminic commented 5 months ago

I added the new parameter: nomad_helper_url

Configuration Agent Value Test Notes
No config doc '' Confirmed Open the nomadURL links in a new tab, using the the old logic. This will be the default for fresh Super.Human.Portal installations
Config doc empty '' Same as above
Other value return value exactly This should be treated as the base URL for nomadhelper.html. Assume that haproxy has been configured correctly if this is set

I also created example JSON to update the configuration documents with Genesis.

Document create_ update_ Test
No config doc Create document Nothing to do Confirmed
Config doc empty BUG: Create duplicate document Update document Update not working currently
Other value BUG: Create duplicate document Update document Update not working currently
Same value BUG: Create duplicate document Nothing to do Update not working currently

If I can get the update_ script working, I'll plan to update it to:

  1. Change the Form for the existing document, if any. This should hide it from the Configuration view.
  2. Create a new document.

UPDATE: I fixed the update script here. Since the SuperHumanPortal.nsf template has this document created by default, we should use this script.

piotrzarzycki21 commented 5 months ago

I added the new parameter: nomad_helper_url

Configuration Agent Value Test Notes No config doc '' Confirmed Open the nomadURL links in a new tab, using the the old logic. This will be the default for fresh Super.Human.Portal installations Config doc empty '' Same as above Other value return value exactly This should be treated as the base URL for nomadhelper.html. Assume that haproxy has been configured correctly if this is set I also created example JSON to update the configuration documents with Genesis.

Document create update Test No config doc Create document Nothing to do Confirmed Config doc empty BUG: Create duplicate document Update document Update not working currently Other value BUG: Create duplicate document Update document Update not working currently Same value BUG: Create duplicate document Nothing to do Update not working currently If I can get the update_ script working, I'll plan to update it to:

  1. Change the Form for the existing document, if any. This should hide it from the Configuration view.
  2. Create a new document.

@JoelProminic I have pushed changes which using new parameter. If it's empty I'm using old behaviour to open url in Nomad. Everything is on the branch - maybe it's time to merge this to master ?

JoelProminic commented 5 months ago

In my tests today, I was not able to trigger the nomadhelper logic. I confirmed that nomad_helper_url was set in the agent, and that this was not a caching issue.

Test Expected Result
nomad_helper_url is empty Open link in new tab Confirmed
nomad_helper_url is populated Open link in existing tab BUG: opens using old logic
nomad_helper_url is invalid Open link in existing tab (but this will fail) BUG: opens using old logic

Unfortunately, this means I could not test the links in the other interface locations or the case when Nomad is not open.

piotrzarzycki21 commented 5 months ago

@JoelProminic how can I reproduce your environment setup?

piotrzarzycki21 commented 5 months ago

In my tests today, I was not able to trigger the nomadhelper logic. I confirmed that nomad_helper_url was set in the agent, and that this was not a caching issue.

Test Expected Result nomad_helper_url is empty Open link in new tab Confirmed nomad_helper_url is populated Open link in existing tab BUG: opens using old logic nomad_helper_url is invalid Open link in existing tab (but this will fail) BUG: opens using old logic Unfortunately, this means I could not test the links in the other interface locations or the case when Nomad is not open.

@JoelProminic ignore please my previous question. I think I have fixed at least second issue. Latest build on branch should have all my changes.

JoelProminic commented 5 months ago

I retested this, and it is working like I specified in my earlier comment. I also confirmed the other interfaces were updated.

Test Expected Browse My Server Bookmarks Installed Apps
nomad_helper_url is empty Open link in new tab Confirmed Confirmed Confirmed
nomad_helper_url is populated Open link in existing tab Confirmed Confirmed Confirmed
nomad_helper_url is invalid Open link in existing tab (but this will fail) Confirmed Confirmed Confirmeed.

However, I see that when I click the unexpanded button and the default action is Nomad, it uses the old Nomad logic rather than the new logic, even if nomad_helper_url is set. I had previously only tested this with the Open in Nomad button.

For the "invalid" case, I see that the URL error is detected in the developer tools. Can we detect this error with nomadhelper.html and open the nmoadURL link in a new tab instead?

Similarly, the case where Nomad is not open already is also a big problem for this updated design. I remember that the state of the service worker was ambiguous in this case. If we can detect the problem, we could open the nomadURL in a new tab instead.

piotrzarzycki21 commented 5 months ago

However, I see that when I click the unexpanded button and the default action is Nomad, it uses the old Nomad logic rather than the new logic, even if nomad_helper_url is set. I had previously only tested this with the Open in Nomad button.

This bug has been addressed, please deploy latest build.

piotrzarzycki21 commented 5 months ago

For the "invalid" case, I see that the URL error is detected in the developer tools. Can we detect this error with nomadhelper.html and open the nmoadURL link in a new tab instead?

Similarly, the case where Nomad is not open already is also a big problem for this updated design. I remember that the state of the service worker was ambiguous in this case. If we can detect the problem, we could open the nomadURL in a new tab instead.

In general we don't have too much option with nomadhelper.html, because from Royale perspective app it's just a page/html file which is being opened inside app in iFrame. I need to investigate whether I can somehow "contact" with opened in iFrame nomadhelper.html or not. @Aszusz mention about some API, which I may try soon. This issue would be the last one to complete this design fully.

JoelProminic commented 5 months ago

Some ideas for communicating with the iframe to detect errors: https://github.com/ternarylabs/porthole https://stackoverflow.com/questions/9153445/how-to-communicate-between-iframe-and-the-parent-site

However, I think we can do some of this inside nomadhelper.html

We'll also need to handle the case where nomadhelper.html doesn't exist - this indicates that we made a mistake while configuring the Vagrant instance, but it shoudln't need to block this action.

piotrzarzycki21 commented 5 months ago

@JoelProminic I was able to sent message from nomadhelper to our application. I'm displaying message to the user which informs that nomad is not opened - message can be change to something more extensive. Changes are in newest build. You have to deploy new version of nomadhelper.html.

JoelProminic commented 5 months ago

As discussed in the meeting today, Super.Human.Portal or nomadhelper.html should open the Nomad link in a new tab if there was any error in nomadhelper.html.

Also, show a message on the bottom of the screen when the link is opened (even if nomadhelper.html worked properly) so that the user knows that they should check the Nomad tab if it didn't focus automatically.

piotrzarzycki21 commented 5 months ago

As discussed in the meeting today, Super.Human.Portal or nomadhelper.html should open the Nomad link in a new tab if there was any error in nomadhelper.html.

Also, show a message on the bottom of the screen when the link is opened (even if nomadhelper.html worked properly) so that the user knows that they should check the Nomad tab if it didn't focus automatically.

@JoelProminic I have pushed changes which opens new tab if Service worker is not registered. There is unfortunately one more case which is completely out of my hands. Here is scenario:

1) Open Nomad Web 2) Open link from Super.Human.Portal - Works 3) Close Nomad Web Tab 4) Try to Open link from Super.Human.Portal - Bug - service worker still exists, so SHP reports that application is opened in Nomad Web tab

piotrzarzycki21 commented 5 months ago

If there is no way to discover closed Nomad tab I believe we should merge this issue if you won't find anything more.