Role based redirects from login to home

What is in the netlify.toml? Do you have redirects in this file as well as the _redirects file?

The netlify.toml lives in the repository root, the _redirects file goes in the publish directory. If, for instance, you are using Create React App, the file would go in the public directory so it is copied to the build directory when building (the build directory is then what Netlify publishes.)

True, the documentation does show the omission of the to field, however it also uses a wildcard e.g.

/admin/*          200!  Role=admin

This is what I created as a quick test. which worked for me.

# Always allow login page
/login    /login    200
# If a `basic-user` serve page
/*    200!   Role=basic-user
# Other send to login
/*    /login    401!

Note: I have a basic-user role rather than authorized. Change the role(s) to suit.

Thanks a lot, I’ve tested this on my published site and it works, I guess the recently upgraded plan was not reflected on CLI.

Other than that, I have moved my _redirects back to my static/ folder, as that folder is the one being pushed as public when deployed and everything works as expected.

To answer your netlify.toml question, it previously had redirect rules which was removed, yet when I created and modify _redirects, the CLI log still shows that it’s processing redirect rules in both _redirects and netlify.toml. Not sure what’s causing that but important thing is it’s working on the deployed site atleast.

On a side note, Role Based Access Control is available on all plans, not just Business, so it has nothing to do with that.

Hi @hrishikesh, not sure if role based access control and role based redirects are the same thing? I was referring to this post.

Role Based Redirects require Role Based Access Controls. If the latter is not enabled, the former will not work.

Thanks for the clarification. So it was a necessary decision to upgrade to Business plan to even utilize role based redirect I assume.

@hrishikesh My previous comment regarding the CLI was that after upgrading and applying role based redirect, when being redirected based off role, it would lead me to an empty page with “Not Found” but when doing it again off of the Netlify Dashboard by publishing the repo, it would work as expected.

There are several open issues on the Netlify CLI repository including the following which may come into play with your usage and is therefore nothing to do with RBAC, or the plan you are on

Okay then great to know that it was a CLI issue.

Sorry to segue this discussion into another, but I’d like to clarify if role-based redirect is behind the Business plan or available for all, as per this discussion. The pricing plans and docs seems to be confusing and emphasizing that a Business plan is required for role-based redirects.

I’m using role-based redirect along with the built in Netlify Identity, so I am not using any 3rd party auth methods. I’m only utilizing serverless functions to apply roles on signup and allowing only those roles to access my site, would I still need a business plan for that feature?

To quote @hrishikesh

I am unable to anywhere in the documentation where is states RBAC is available only available on the Business plan. Can you point to where it says that @NikShafiq?

The post referred to here also mentions the use of JWTs which as per this post are only available on Business. If wishing to use an External provider this also requires a higher plan.

This is possible what is the Netlify access contol on the pricing page is referring to.

I’m referring to this, where it mentions:

Restricting access to sites is easy when you use Netlify. With Role Based Redirects, a pro-feature that is available with the Teams Business plan or above

which gives the impression that role-based redirects is behind a business plan.

This article was published January 31, 2019 (three years ago.) Much will have changed since then.

1 Like

Hey there, @NikShafiq :wave:

Thanks for bringing this to our attention. I have surfaced your feedback to the team that owns our blog to see if we can change the outdated post.

In the interim, are there additional questions we can answer for you at this time?

Thanks for that Hillary, updating the docs would give much more clarification on what is available on the plans.

Just to clarify, RBAC and Role Based Redirects are available on the all plans, but the use of 3rd party Authentication is for Business plan only. Does this also mean that the use of GoTrue directly is not considered 3rd party as the Identity Widget is built on top of it?

GoTrue is a first-party library (it’s owned by Netlify) and same is the case with the Identity Widget. Using that is supported on all plans.

Hi,

I really struggling getting role based redirects to work. I created my own login form with GoTrue. Login works perfectly fine and it returns the correct Roles in users meta. I only noticed that the role value is empty. However, even so the conditions are setup to allow the admin to visit the route, it keeps redirecting to the 404 page. I even switch over to the Business plan, still I cannot get it work. The users roles meta data has no effect whatsoever.

[[redirects]]
    from = "/"
    to = "/account/login"
    status = 200

[[redirects]]
    from = "/*"
    to = "/404.html"
    status = 404
    conditions = {Role = ["admin"]}

[[redirects]]
    from = "/*"
    status = 200
    force = true
    conditions = {Role = ["admin"]}

[[redirects]]
    from = "/*"
    to = "/account/login"
    status = 401
    force = true

Login script

if (!this.auth) {
                        console.log('No Auth found')
                        return;
                    } else {
                        event.preventDefault();
                        this.loading = true;
                        this.auth
                            .login(this.inputElements[0].value, this.inputElements[1].value, true)
                            .then(response => {
                                this.loading = false;
                                const userName = response.user_metadata.full_name;
                                this.showMessage(
                                    `<p>Log in successful! </p><p>Welcome back ${userName}</p>`, true
                                );
                                this.$dispatch('logged');
                            })
                            .catch(error =>{
                                this.loading = false;
                                this.showMessage(`Failed to log in :( <p>${error.json.error_description}</p>`, false, true)
                            }
                            );
                    }

Hi @nolafs

Rules are processed top to bottom. The likely issue here (I suspect) is the 404 rule catching everything first and the 200 rule never triggering. Try changing the rule order.

Thanks,

I checked it by simplifying the redirects.

[[redirects]]
    from = "/clients/*"
    to = "/account/login"
    status = 401
    force = true

[[redirects]]
    from = "/clients/*"
    status = 200
    force = true
    conditions = {Role = ["admin"]}

Still, user with the correct roles, admin, hitting the /clients/* route, still redirects to the account/login page. Perhaps using goTrue login is not correct. I really have no idea. I am getting the same behaviour using the _redirect file. It seems GoTrue meta data is completely ignored.

You need to put the 200 rule first, the 401 second. This allows anyone authorised through, anyone who is not will then get redirected to the login page.

For example, here is the _redirects file some a test site I have

# Always allow login
/login        /login    200

# Always allow unauthorised
/unauthorised    /unauthorised    200

# Staff-only pages
/staff/*    200!   Role=staff
/staff/*    /unauthorised    401!

# All other pages
/*    200!   Role=basic-user
/*    /login    401!

Thanks, I found the issue with my login. Api root has an error. Pointing to wrong end point. A mix up with a previous project. Sorry for wasting all of your time.

1 Like

Thanks for coming back and letting us know @nolafs. Glad everything is working now!