two changes -- a new check_proxy function and a change in to use_proxy check_proxy is a more REST-friendly way to ensure determine that a  user Narrative session is started, and that all potential error  conditions are handled. The primary difference from the sister function and also oddly the parent (code-wise) is that use_proxy is oriented towards interaction with the user. E.g. it uses a redirect to a login page rather than a 401 unauthorized response. We cannot use check_proxy at the moment, though, because it requires a different route prefix (check_narrative rather than narrative), and Jupyter contains some logic based on this and will 404. The use_proxy change is to use the path rather than the full url for the n parameter in the redirect to the loading.html page. This makes it  consistent with other routing (e.g. it routes to /loading.html not  using the full url) in which it is implicit that we are on the same  origin. Actually, supplying the full url the loading.html is potentially dangerous, as it asks the loading page to redirect to any arbitrary url. The kbase-ui otherwise only allows navigation on the same origin (e.g.  in the router, and in the nextrequest routing.)
two changes -- a new check_proxy function and a change in to use_proxy
check_proxy is a more REST-friendly way to ensure determine that a 
user Narrative session is started, and that all potential error 
conditions are handled. The primary difference from the sister
function and also oddly the parent (code-wise) is that use_proxy is
oriented towards interaction with the user. E.g. it uses a redirect
to a login page rather than a 401 unauthorized response. We cannot use
check_proxy at the moment, though, because it requires a different route
prefix (check_narrative rather than narrative), and Jupyter contains some
logic based on this and will 404.
The use_proxy change is to use the path rather than the full url for the
n parameter in the redirect to the loading.html page. This makes it 
consistent with other routing (e.g. it routes to /loading.html not 
using the full url) in which it is implicit that we are on the same 
origin. Actually, supplying the full url the loading.html is potentially
dangerous, as it asks the loading page to redirect to any arbitrary url.
The kbase-ui otherwise only allows navigation on the same origin (e.g. 
in the router, and in the nextrequest routing.)
psnovichkov/narrative,mlhenderson/narrative,mlhenderson/narrative,psnovichkov/narrative,kbase/narrative,briehl/narrative,kbase/narrative,briehl/narrative,pranjan77/narrative,pranjan77/narrative,jmchandonia/narrative,msneddon/narrative,briehl/narrative,briehl/narrative,pranjan77/narrative,psnovichkov/narrative,pranjan77/narrative,kbase/narrative,mlhenderson/narrative,kbase/narrative,kbase/narrative,briehl/narrative,pranjan77/narrative,briehl/narrative,psnovichkov/narrative,msneddon/narrative,jmchandonia/narrative,psnovichkov/narrative,briehl/narrative,pranjan77/narrative,msneddon/narrative,pranjan77/narrative,psnovichkov/narrative,mlhenderson/narrative,jmchandonia/narrative,psnovichkov/narrative,msneddon/narrative,jmchandonia/narrative,msneddon/narrative,jmchandonia/narrative,mlhenderson/narrative,jmchandonia/narrative,mlhenderson/narrative,msneddon/narrative,kbase/narrative,msneddon/narrative,jmchandonia/narrative