User security when embedded objects are involved

[parkjammer]

The Setup:

• I have a PARENT UX that I would like to be NOT SECURED so the overall app is available to all users, whether or not they are registered or logged-in. No fuss, no muss.
• However, I have one or two panels that do require a user to have an account and be logged-in.
• I have created panels with separate CHILD or "embedded UX" objects. I've then ENABLED SECURITY for ONLY THESE UX files.

My Expectation:

• I would expect casual users who are NOT LOGGED-IN to be able to access most of the application.
• When a panel that refers to a secure CHILD (embedded UX) is selected, the user would be redirected to the standard "redirect login".

The problem:

• It seems to be that if there is ANY CHILD UX that is has SECURITY ENABLED, then the ENTIRE PARENT UX is acts as if it requires a login.
• The result is that the automatic "redirect login" page is activated whenever the PARENT UX is accessed.

Questions:

• Is there a way to make a login request occur for ONLY a CHILD UX that has security enabled?
• NOTE: the goal is to allow most of the app to be used without a login

Options I see:

• I can govern access to the menu options via security and remove security from the separate "embedded UX" objects.
• I might be able to have the Embedded UX (child) objects be unprotected and have them call another embedded UX (grandchild) and see if Alpha security picks that up.
• I could change my paradigm and use the standard "login or peristent-login, and then go to the PARENT UX".

Not a panic; I can get around it via the options noted. Just checking to see if my assumptions about how security when PARENT and CHILD objects are involved is right or wrong... and if there is simply an easy or best-practice solution.

Thanks for taking a look!

[CharlesParker]

Re: User security when embedded objects are involved

if no other option exists, I think I would setup a free user account and auto fill the login - enabling security from the beginning, then if they click on a button that does not allow them access redirect them to the login for "registered users" similar to groups - in fact use groups to create the free user account that way you can stop them.
Now, the button to get to the "paid" content would only bring up a window with a confirm button which would then direct them to register or the cancel button would keep them in the free content. the message in the window would allow them to register for a paid account (a button choice to redirect them to signup), and of course a cancel button to stay within the free content area as stated previously. Going further, you could hide this button and show the direct link button if they belonged to the "paid content" group and hide the button offering sign up, etc.
In this way you would enable security from the beginning.
Hope this helps, if there is no other way!

[parkjammer]

Re: User security when embedded objects are involved

Thanks Charles. All options are good options.

I was simply a bit surprised that "any embedded and secure UX" forces the "entire parent UX to be secure".

Will choose an option today.