How do you require a user to be logged in on a router page?

Ask the community
, , , ,
1

I would like to do the following:

  1. User navigates to a router controlled page

  2. Router determines if the user is logged in.

  3. If logged in, continue with routing

  4. If not, allow the user to log in

  5. Check what Collaborator roles (as opposed to Member roles) the user has, and determine if that user has permission to view the router controlled page.

  6. If user has the right permissions, route them to the page

  7. If the user does not have the right permissions, route them to some other page

How can I do step 4? When you navigate to a router controlled page, the router code runs, then once routing is done, your page code runs. promptLogin is only available on the client, so somehow, the router has to detect the login status, then tell the page about it so the page can prompt for login.

I tried using the router to detect if the user was logged in, then send data back with the router response, but this didn’t work. It’s really slow, so you see the page for a second or two before the login screen comes up. Yeah, I could hide everything on the page, but this all seems really hokey. Is there any way I could make better use of the router to do this?

I think it must be possible, because if I use Wix’s built in page permissions (for example, only Admin can look at this page), and then I navigate to the page, Wix forces the login to happen. If I just cancel out of the loginPrompt, Wix redirects me back to the home page. I’m not sure how this works, or if the same mechanism is available to me. I do know that when Wix does the intercept, my masterPage.js and pageCode onReady don’t run. I think Wix is intercepting before any page code or onReady is called. I don’t suppose we have access to the same interceptor…

Unfortunately, I’ve read everything I can find about Wix routing, and the docs and examples are inadequate in this area.

Barring that…the only reason I’m doing this at all is because I was hoping to use Collaborator Roles, and not Member Roles. I could skip all this nonsense if I use Member Roles because I can set up all the router page permissions to the member role. But my hunch is that for what I’m doing, I want these people in Collaborator Roles, not Member Roles.

I thought that using Member Roles was for setting up a whole Members area and allowing people/customers/general public to request/sign up for your site. I really don’t want that. I just want a few of the store’s staff members to be able to get in and do some things. There are other things they need to do as well, like post Blog articles and access the media manager. This is why I was using Collaborator Roles. Should I be using Member Roles instead?

Thanks in advance

2

See the Stripe Payment Processing example for a solution. This example handles three types of site visitors: anonymous, signed in (freemium), and paid (premium).

3

I did look at that example extensively. It is not what I’m trying to do.

I stated in my question above that:

“I think it must be possible, because if I use Wix’s built in page permissions (for example, only Admin can look at this page), and then I navigate to the page, Wix forces the login to happen…”

And this is exactly what that example is doing. It is using Wix’s built in page permissions to put up the login page. ie, every page that requires login is set up in the page permission settings to Members Only .

Members Only uses Member Permissions and optionally, Member Roles. I have Collaborator Roles, not Member Roles. I would like to gate access to pages based on COLLABORATOR ROLES other than Admin.

There is no option in the page permission settings to choose Collaborator Roles other than Admin, which I can’t use because I don’t want to make people Admin on the site. So it appears that I cannot use Wix’s built in page permissions if I want to gate access based on a Collaborator Role.

For this reason, I was trying to do it by using the Router.

As I said, I did this by passing data back from the router, and then allowing the page code to put up the loginPrompt. But it’s hacky and crappy because the page code actually runs and the DOM is built (and displayed) before the login modal can be put up.

Wix must be running an interceptor that replaces the DOM with the login modal BEFORE actually running any page code or building the page’s DOM.

I’ll ask again:
Is there a way to make the router allow a non-logged in user to log in before running the page code or building the DOM?

The only way I can think of is to create a dummy page that has nothing on it. Use the router to detect non-logged in status, and then redirect to the dummy page. The dummy page calls loginPromt to put up the login modal, and once logged in, redirects the user back to the page they were trying to look at. This seems like a hacky, ugly approach.

Is there a more elegant way of doing this? (again…gating access on Collaborator Roles, not Member Roles, and detecting that the user is not logged in and putting up the loginPrompt).

Or should I just give up and use Member Roles?

Thank you

825×497 45.2 KB

4

That example does use routers, and was specifically written as an example on how to user routers.

The example only handles simple cases. If you have special requirements, then you can handle them in code, and change the way the routers behave. The example will give you good start on using routers.

5

I know the example uses routers. My central question was not so much about whether the example uses routers, but whether there’s an example of detecting that a user is not logged in and then allowing them to log in that does NOT use Wix’s built in page access.

Again, the example does not use Collaborator Roles, or check its own permissions. It delegates all that to Wix.

To be clear, if I don’t care about offering a user the opportunity to log in, then none of this is even a question. But I would like to allow a non-logged in user the opportunity to log in, then run the router to see if that user has the proper permissions.

6

But while I’m at it, the example does confirm something for me that I’ve been stewing about. The router API and module are sort of broken, in that if you import WixRouterSitemapEntry, there are red squigglies and an error that tells you that there is no exported member. For this reason, I was convinced I had to be using this stuff incorrectly.

But the example’s router sitemap also has the red squigglies. So now I know that I’m not using this wrong. There is something broken about how the module is built.

912×89 14.9 KB

7

Thanks for reporting the issue with WixRouterSitemapEntry. It’s on our backlog to fix.