Recently Browsing 0 members
No registered users viewing this page.
I just want to point out this framework for making html apps https://onsen.io/
it's compatible with jquery, angular, vue, react or any other js framework.
So far I made an app using this and bootstrap with https://propeller.in/
for the desing and some libs like jquery and lodash for the app logic
I prefer this to other alternatives like ionic since it does not bound you to angular or react.
I've been getting more and more into building full fledged web apps using PW as a framework. I use PW for data modeling and storage, user management, etc., and extend the Page class for different templates to add functionality to specific types of pages/data models. It is a very simple and powerful way to develop.
However, one thing that I have struggled with is finding the right way to approach page view access for users of an application (This would also apply to a password-protected area of any PW site). I'm going to try and boil this down to the most simple, common scenario, and go from there:
I am building an app where every page in the app (except for the login screen) should be password protected. Should I...
1. Turn off page view access in the template access settings for the guest user and use the settings to redirect the user to a login page.
This has the drawback that you cannot disable guest view of the home page (a built-in PW limitation that seems a bit arbitrary). You are also limited in how you can define what to do when the page is not viewable (you must use the options provided in the admin interface), and you do not have the option of continuing to load the page with an alternate view (for example, a login form). Also, sometimes it requires configuring a lot of settings for a lot of different templates. It also doesn't give you page-specific access control.
2. Leave the access settings wide open but write some code at the top of my template files, init.php, or ready.php to redirect users who are not logged in.
This has the disadvantage that it only applies if ProcessWire gets that far into the page load process, and it doesn't effect any other aspect of ProcessWire (for example, whether the page is available in a $pages->find()). If I wanted, I could allow anyone to reach any page and just show/hide the content based on the user's permissions or role. If the user doesn't have permission, I could keep them on the same page but show the login. Once they logged in, they'd be on the page they were originally looking for.
3. Write my own hook before or after Page::viewable and/or ProcessPageView::execute (or somewhere else?) to switch access on or off and redirect based on my own requirements.
This should be more reliable and secure than #2 and more flexible than #1, but it feels kind of like reinventing the wheel. Maybe the best approach is some combination of #1 and #3, with #2 reserved only for showing and hiding individual sections of a page that is already viewable.
I'd be very interested to hear how others are handling this.