Allow internal redirect to URI x, but deny external request for x?

[J. Lewis Muir]

On 08/30, j94305 wrote:
> I've been following this, and I would take a slightly different approach.
> 
> 1. Serve all apps under /{app}/releases/{version}/{path} as you have them
> organized in the deployment structure in the file system.
> 
> 2. Forget about symbolic links and other makeshift versioning/defaulting in
> the file system.
> 
> 3. Use a keyval mapping to handle redirections (307) of
> /{app}/current/{stuff} to /{app}/releases/{currentVersion}/{stuff}, where
> the keyval mapping provides {app} => {currentVersion}. You can update an
> manage this during deployment.

Sorry, I forgot about your post!  Thank you for your suggestions!

Is this a keyval?

  https://nginx.org/en/docs/http/ngx_http_keyval_module.html

> We usually include this in a CI/CD pipeline after deployment to dynamically
> switch to the last version (using a curl request to the NGINX API). If you
> can't use keyvals, use a static map and dynamically generate that "map"
> directive's mapping. Restart NGINX to reflect changes. Keyvals let you do
> this on the fly.

Is this a static map?

  https://nginx.org/en/docs/http/ngx_http_map_module.html

And by "dynamically generate" do you mean generate the map directive as
a config file that would be included from the main config and then cause
nginx to reload its config?
 
> The major advantage of this approach is with updates. You are most likely
> going to run into issues with browser or proxy caching if you provide
> different versions of files/apps under the same path. By having a canonical
> form that respects the version structure, you are avoiding this altogether.
> Yet, you have the flexibility to run hotfixes (replace existing files in an
> existing version without creating a new one), or experimental versions
> (which won't update the "current" pointer).

Interesting.  What I was trying to do with $realpath_root, I thought
was similar to what you're describing.  However, when you mention
browser or proxy caching, then I'm not sure.  Are you suggesting
serving from a different URI for each version of the app?  If not,
then I don't understand how your proposal behaves differently than the
symlink+realpath idea.  (But this may be because you wrote this on Aug
30, and the symlink+realpath idea had not been clearly stated yet.)

> I would try to keep the complexity low.

Agreed!  However, changing a symlink (albeit with some nginx config
changes to use $realpath_root and such) is pretty simple to me, so it's
a little harder for me to see using a keyval or a static map as keeping
the complexity low.  But if I understand your proposal correctly, it
would be more straightforward in terms of not needing to use symlinks at
all and not needing to worry about $realpath_root vs. $document_root.
Instead, you just use variables, and to update the variables, you just
use the API if using a keyval, or cause nginx to reload its config if
using the static map.

Thank you for the suggestions!

Regards,

Lewis