-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compare the page for nomad_helper_url to the expected nomadhelper.html #57
Comments
@JoelProminic I was thinking to have that comparision during configuration fetching, where we are retrieving nomad_helper_url. Where do you think it should actually happen if not in that moment ? |
I'm moving this for the next release. I have started implementing this. Should be ready soon, but let's not hold this since our first target is internal use. |
I think that running this just after calling ConfigRead make sense. You can then load the |
…cal one - Logic generate hashes and compare both content hashes for each file (reference #57)
I have implemented initial version, but it doesn't work yet as I wanted to so, it's still require a bit more time. I have pushed my changes to branch. I will notify about significant progress and when it will be ready for tests. |
alongside comparision into Proxy (reference #57)
@JoelProminic I think I have whole comparision of nomadhelper.html ready. I'm using HTTPRequest to load local and remote files. I'm using native JS module called "crypto" to compute hashes for both files. Not we should discuss what kind of message we should display to the user. |
Here is a message based on the existing Nomad check
This should be displayed once per day per user. |
We also want to compare the page for nomad_helper_url to the expected nomadhelper.html and show a similar warning if they don't match exactly. Genesis doesn't have access to install nomad_helper.html, so we want to have SuperHumanPortal verify that the nomad_helper.html installed by the administrator matches the copy under
resources/
.If we are reading nomad_helper_url, then we need to safely handle the case where the URL doesn't resolve properly (because it was not properly configured). I would expect the administrator to test this, but until it is fixed, Super.Human.Portal should use the default logic instead.
A mismatching nomad_helper.html is not necessarily a blocker, so I think we should attempt to use the helper anyway in this case. If this fails, it should be handled by the callback logic.
Originally posted by @JoelProminic in #54 (comment)
The text was updated successfully, but these errors were encountered: