Allow some project pages to be viewed without login

Hi-

I’m using Perspective 8.1
I have a project with several pages. Currently, the project is setup to require a login for all pages.

I’d like one page (a general status page) to be viewable without login. I’ve setup a page URL for the status page, and can get to it directly from the browser, but only with a login (like the rest of the project).

I know one option is to move the status page/views to a separate project, but I’d rather not go through that hassle. Any other options?

Thanks.
-Shane

You can allow launching the project without authentication, but then set the security on each page to determine if they need to be authenticated or not

Thanks for the suggestion.

I’m not certain how to set the permissions for an individual page. I can set the view permissions on the primary view for the page, but that doesn’t seem to work quite the same. Is this what you meant?

When I set the ‘Project Properties/Perspective/Permissions’ to authenticated, it gives the expected and nice “Log in to continue” page and prompts for name and password whenever you try to access any page.

When I set the project permissions to ‘public’ and then configure the individual ‘view permissions’ to be ‘authenticated’, it doesn’t prompt the user to log in, it just says “Access Denied. You do not have permission…”. Is there any way to get it to prompt for the log in instead on those individual views (pages) that require it?

Thanks.
-Shane

Not sure if the startup script runs if access is denied but you could try using that to check auth and call the login function if not. Regardless though, the operator should still have access in the header to login though right?

I handle this by creating all of the resources in an inheritable project and creating child projects. I then set up URLs for the pages I want that child project to have access to and set the permissions at the project level

Not sure if this is best practice though

1 Like

There’s not a way to configure required permissions at the PAGE level in Perspective. What I would recommend is to place this “status” page in a different project altogether - one which does not require permissions. That way you can leave security in place on your current project, but the status page can be viewed by anyone. You’ll need to update any navigation references you have in place to switch from “page” navigation to url navigation, since the status page is in a different project.

Since views can be in views containing views, wouldn’t it make more sense to have security be on a page level?

I would like to have a unauthenticated front page, a authenticated detailed page, and a role restricted deep dive page or view in the same project, sharing the same session properties. I can set these permissions but navigating to the more restricted pages simply throws a access denied instead of prompting the anonymous user to login. Is there a solution to that or plans to make this more fluid?

If you have a “template” which requires specific permissions and that template could be in use on multiple pages, security settings on the page level would not safeguard you against someone placing that view into another page and making it visible - unbeknownst to you. Said another way: if we had page-specific security settings in place, there’s nothing to stop another designer from placing the same views from a restricted PageA into PageB where PageB has no such security and therefore the views are visible to anyone.

View-scoped security is the only current way to securely restrict content across multiple pages/sessions.

There’s an option available:
I would recommend that in the View onStartup Event you make a check to see if the user meets your defined criteria, and if they don’t then you could request they login. There is a problematic scenario, however, in that if they are unable to ever enter credentials which would supply them the valid permissions then they would be trapped in an authentication cycle until they change the URL to navigate to a different page.

An alternative would be to open a Popup which describes why the View is unavailable to the user, and provide within that Popup a way to re-authenticate.

1 Like

I appreciate the detailed reply and follow the logic now. Thank you.

I like the information pop up idea. Are there still no plans to have a customizable access denied page?

Also, could the access denied page first ask a user to login if their connection is anonymous?

There are no plans to my knowledge which would provide a customizable “Access Denied” page, but you could also just do this yourself.

You could create your own “AccessDenied” View, and anywhere you would supply a View that requires permissions, you could bind that viewPath property and supply logic in a transform to determine if the current user has the required permissions. If they do, then you set the viewPath property to the desired view - if the user lacks the required permissions, then set the viewPath property to your AccessDenied view.