Skip to content
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

update URLs for update sites when they change on the wiki list #66

Open
carandraug opened this Issue May 29, 2018 · 6 comments

Comments

Projects
None yet
3 participants
@carandraug
Copy link

commented May 29, 2018

As mentioned on the discussion to issue #65 the updater does not update the sites URLs when they change on the wiki list.

@frauzufall frauzufall self-assigned this Dec 18, 2018

@frauzufall

This comment has been minimized.

Copy link
Member

commented Dec 18, 2018

I want to fix this since we need it for the HTTPS support. Here's how it could look like:

  1. load local list of update sites
  2. load remote list of update sites
  3. pair up by name
  4. if URLs not equal, use remote URL

However this would mean that if someone modifies the URLs manually the updater would always reset them again. I would therefore add an attribute to an update site storing the manual choice and not update the URL to the remote URL in this case.

This would only work for future manual changes, anyone who edited these URLs in the past would get the default URLs from the list of update sites back.

@ctrueden

This comment has been minimized.

Copy link
Member

commented Dec 18, 2018

I think a scheme like this makes sense. There are some other related edge cases to consider:

  • Someone adds an update site "Foo" to the list manually, because it is not included on the central list of update sites. Later, the Foo site is added to the list of update sites. In this situation, we want Foo from the remote to take over for all users who had added Foo manually before.
  • Someone has "Baz" enabled from the list of update sites. Later, Baz becomes obsolete, merging with another site, so Baz is removed from the list of update sites. In this situation, we may want to either: A) remove Baz from the list for them; or B) warn the user that Baz is no longer listed, and they may want to consider removing it from their list manually.
@carandraug

This comment has been minimized.

Copy link
Author

commented Dec 18, 2018

  • Someone adds an update site "Foo" to the list manually, because it is not included on the central list of update sites. Later, the Foo site is added to the list of update sites. In this situation, we want Foo from the remote to take over for all users who had added Foo manually before.

I'm not sure this is good. The manually added "Foo" site may not be the "Foo" site that is later added to the central/remote list. Say I have a "micron" update site for internal use which our users and facility systems use. Someone else sets a "micron" site on the central/remote list. This buggers up all our systems and our users on the next upgrade.

The name of the site should be for convenience and readability, but what really matters is the actual URL. That this changes automatically under my feet sounds worrying. It's ok for the server in the URL to then redirect because by selecting that URL, the user claims to trust the server. This is different from having something else (the ImageJ list of update sites), changing the URL itself.

So I don't think this is a requirement to support https. I also don't think that updating the list of sites in a central list of sites is the solution when one update sites moves location. The responsibility of this falls on the update site maintainer which means setting up a redirect. This redirect may even be Moved Permanently, in which case I guess it may make sense to update the URL.

@ctrueden

This comment has been minimized.

Copy link
Member

commented Dec 18, 2018

The name of the site should be for convenience and readability, but what really matters is the actual URL.

I agree. To clarify my point, here are two scenarios and how I would propose handling them:

Scenario 1

  • You create a Micron update site at https://myfacility.edu/micron, instructing your users to add this update site manually to their list of update sites locally.
  • Some other organization adds a Micron update site at https://theirinstitute.org/micron to the list of update sites.
  • The Updater is smart enough to realize that these two Micron sites are not the same thing, because the URLs differ. The manually added Micron update sites are treated as "local only", with the other Micron update site also being listed independently.

Scenario 2

  • Some organization creates a Micron update site at https://theinstitute.org/micron, at first for internal use only, and instructs their users to enable it manually locally for now.
  • Once bugs are ironed out, the organization adds this same Micron update site to the list of update sites.
  • The Updater is smart enough to realize that these two Micron sites are the same thing, because the URLs match, so all the manually added Micron entries are not treated as "locally modified"/"local only" anymore.

How to achieve it

When a site is added locally (as opposed to being edited from an entry originally added via the list of update sites), it gets a special status "local only". Whether it retains that status after a new list of update sites is retrieved and compared will depend on the situation, as described above.

I do not think it is trivial to consider and code all these various different edge cases, but I think it is helpful if we can make things work as seamlessly as possible over time as the list evolves.

@frauzufall Perhaps it makes sense to assign each site on the list a unique ID, and store those locally, so that it becomes unambiguous whether a particular local site is really the same site linked to the list of sites.

frauzufall added a commit that referenced this issue Dec 18, 2018

Update URLs of available update sites #66
* UpdateSite: String modifiedUrl storing URL in case it's manually adjusted
* modifiedUrl is also logged in the update site entry in db.xml.gz
("url-modified")
* UpToDate plugin checks if list of available update sites contains
updated URLs
* in case URL was changed manually, it will not be updated to remote
version
* otherwise the local URL entry of the update site will be updated
@frauzufall

This comment has been minimized.

Copy link
Member

commented Dec 18, 2018

@carandraug I understand your concerns. I was not happy about matching the update sites by name, I just wanted to make sure any installation supporting HTTPS will also use HTTPS without users having to manually update their URLs. I will look into your PR #67 next.
@ctrueden having an ID sounds very reasonable.

@frauzufall frauzufall referenced this issue Dec 21, 2018

Open

New version of the ImageJ Updater #70

2 of 6 tasks complete
@frauzufall

This comment has been minimized.

Copy link
Member

commented Jan 9, 2019

As I commented here, we do need to update these URLs in order to serve HTTPS updates to existing installations because the ImageJ server has no redirect from HTTP to HTTPS for requests from the updater (@ctrueden correct my if I'm wrong). I would love to get this going, any suggestions welcome. We could also whitelist links from @carandraug's server in the code so that they will not be affected.

frauzufall added a commit to imagej/imagej-ui-swing that referenced this issue Feb 26, 2019

Dialog to handle remote URL changes of activated update sites
* in case an activated update site is from the available update site
list and gets an URL update, this dialog can ask for confirmation of the
URL update
* user can accept URL update or keep current state
* if user keeps current state, choice can optionally be remembered
* choices can be made for all affected update sites at once or
individually
* current main use case is changing URLs from HTTP to HTTPS
* depends on imagej/imagej-updater#71
* touches imagej/imagej-updater#66

frauzufall added a commit to imagej/imagej-ui-swing that referenced this issue Feb 26, 2019

Adds Update Site URL status check to Updater procedure
* during update all URLs from the available update site list are checked
for updates
* if the update site is disabled, the URL is updated automatically
* if the update site is enabled, the user is asked for confirmation of
URL change
* depends on imagej/imagej-updater#71
* touches imagej/imagej-updater#66

frauzufall added a commit to imagej/imagej-ui-swing that referenced this issue Feb 26, 2019

ReviewSiteURLsDialog to handle remote URL changes of activated update…
… sites

* in case an activated update site is from the available update site
list and gets an URL update, this dialog can ask for confirmation of the
URL update
* user can accept URL update or keep current state
* if user keeps current state, choice can optionally be remembered
* choices can be made for all affected update sites at once or
individually
* current main use case is changing URLs from HTTP to HTTPS
* depends on imagej/imagej-updater#71
* touches imagej/imagej-updater#66

frauzufall added a commit to imagej/imagej-ui-swing that referenced this issue Feb 26, 2019

Adds Update Site URL status check to Updater procedure
* during update all URLs from the available update site list are checked
for updates
* if the update site is disabled, the URL is updated automatically
* if the update site is enabled, the user is asked for confirmation of
URL change
* depends on imagej/imagej-updater#71
* touches imagej/imagej-updater#66

frauzufall added a commit to imagej/imagej-ui-swing that referenced this issue Feb 26, 2019

ReviewSiteURLsDialog to handle remote URL changes of activated update…
… sites

* in case an activated update site is from the available update site
list and gets an URL update, this dialog can ask for confirmation of the
URL update
* user can accept URL update or keep current state
* if user keeps current state, choice can optionally be remembered
* choices can be made for all affected update sites at once or
individually
* current main use case is changing URLs from HTTP to HTTPS
* depends on imagej/imagej-updater#71
* touches imagej/imagej-updater#66

frauzufall added a commit to imagej/imagej-ui-swing that referenced this issue Feb 26, 2019

Adds Update Site URL status check to Updater procedure
* during update all URLs from the available update site list are checked
for updates
* if the update site is disabled, the URL is updated automatically
* if the update site is enabled, the user is asked for confirmation of
URL change
* depends on imagej/imagej-updater#71
* touches imagej/imagej-updater#66
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.