#6529 Login overlay
Create a decorator or require_access alternative that allows the page to render but causes a login overlay dialog to be displayed over the page, similar to this mockup.
The overlay should load an iframe from the URL specified in auth.login_fragment_url with the appropriate return_to info provided, which should submit to _top to reload the source page.
Also, the overlay should be a little lighter than the mockup and the box should be movable so that the underlying page can be inspected (although not interacted with) as the purpose behind this is to showcase what can be done when logged in.
A default fragment implementation should be provided based on the default login view in allura.controllers.auth.AuthController. A SFX fragment implementation will need to be created, as well, for SF.
For SF, we should consider putting the CSS in the parent sftheme styles so that it can be re-used with sfpy.
allura:cj/6529sftheme:cj/6529sfx:cj/6529Allura/allura/templates/login_fragment.htmlis missingrequire_accessneeded in theprocess()method since it's already happening in_check_security? Is it because _check_security is running but merely doing an overlay and not blocking the request? That is a little unsettling. We'll have to be careful when we use login_overlay within _check_security.lib/security.pysettingc.show_login_overlay. I'm not sure exactly how to make it better though. Instead ofrequire[_access]functions doing it, the controller could catchHTTPUnauthorizedand setc.show_login_overlay. I think it's a little better to have that in the controller layer, but then we have a few lines of boilerplate in every controller that uses it. A helper function could do it? But that is starting to seem silly since it's just a few lines of code right now.I totally forgot to
git adda couple of new files, so that's why it's broken. I force-pushed those changes if you want to take a look, but...I also wasn't super happy with putting the logic in
require*but wasn't sure of a better approach. I went with putting it in there because the view code is inmaster.html, so I figured it was already "system level," but I'm not happy with it. Also, the reason for the extrarequire_accesscheck inprocessis because we don't want to show the overlay for the action methods, which is another side-effect of the logic being in the wrong place.I'm thinking now what would be better would be to make this a decorator that catches and overrides the
HTTPUnauthorized/ login redirect for only the decorated view. I'll look in to making that change as well as adding tests.Refactor and tests (force) pushed to:
allura:cj/6529target=_topon Forgot pwd and Create Account links (sfx)# auth.login_fragment_urlindevelopment.iniso its discoverablelogin_overlay(theexceptionsparam really confused me since I initially though it was for http exception types)allura_theme_macros.login_overlay()and re-use the Allura version directly instead of duplicatingPushed to all of:
allura:cj/6529sftheme:cj/6529sfx:cj/6529Btw, I couldn't get a decorator to work because the
_check_securityhappens before the view method is even resolved so the decorator never comes in to play. I definitely don't like theexceptionsparameter but I couldn't figure out a better way to do it. I'd love suggestions.