Authenticated Imagery Sources with TileImageLayer

[AkeluX]

TileImageLayer forces the origin on image requests to "anonymous", see:

https://github.com/NASAWorldWind/WebWorldWind/blob/master/src/layer/TiledImageLayer.js#L480

image.crossOrigin = 'anonymous';

This doesn't work for servers requiring authentication. The appropriate value in this situation is "use-credentials".

As discussed with the development team, there is an upcoming refactoring of the image layers that will decouple the tile retrieval mechanism. This issue will be addressed as part of this refactoring.

[pdavidc]

@Beak-man I have an update from a conversation with @AkeluX this morning. @AkeluX made a good case for keeping this PR as-is. By exposing the crossOrigin retrieval option as a property, rather than through the constructor as we are considering, eliminates the need to modify every TiledImageLayer subclass constructor.

This made a lot of sense to me. What to you think?

[Beak-man]

@pdavidc, I concur with @AkeluX considering that we want to release 0.9.0 soon. TiledImageLayer has seven subclasses and each one would need to be refactored.

I do like your idea of using a configuration object for the constructor. We wouldn't be redesigning from scratch, since two of TiledImageLayer's subclasses — WmsLayer and RestTiledImageLayer — make use of configuration objects to feed the TiledImageLayer constructor (each one in a different manner, and RestTiledImageLayer's is entirely optional, it's not being currently used). Refactoring the seven subclasses with such a pattern may be considered a big task considering we just want to address a single property.

Furthermore, I just discussed this with @markpet49 and he pointed out that just using a 'plain', user-made object as configuration (as is the case with the two aforementioned subclasses) instead of one controlled through a constructor of its own (i.e. a class), is kind of flaky and prone to errors. To have good control over the configuration parameters, we would need to design a 'LayerConfiguration' class or such. I didn't consider this before talking with Mark, and I concur with him. Again this widens the scope of this task and increases the amount of code to maintain if we implement it.

I think the authors of WmsLayer and RestTiledImageLayer used configuration objects as a way to work around the amount of parameters for TiledImageLayer's constructor, but if we do a refactor to consider a configuration class or even just a plain, arbitrary object, it should be considered as a separate, broader task that has more to do with homogenizing the usage of TiledImageLayer by its subclasses, than considering a single property.

[pdavidc]

@Beak-man That's a good summary of the key points to consider.

Let's merge #268 as-is, and revisit this when the need arises.