Role based redirects does not work as intended in dev mode

Support
,
1

netlify-cli/8.13.0 linux-x64 node-v16.6.2

I have a setup where I rewrite /* to /pro/:splat for pro users and /* to /free/:splat if the first rule was not applied. If I only have the second (free) rule everything works, but if I add the first rule then /index.html returns 404 in dev abd dev --live (works on production).

These are the rules:

[[redirects]]
  from = "/*"
  to = "/pro/:splat"
  status = 200
  conditions = {Role = ["pro"]}
[[redirects]]
  from = "/*"
  to = "/free/:splat"
  status = 200

If I remove the first rule I get 200 on index.html if I keep it I get 404. My guess is that for some reason role based rewrites in dev mode are executed even if the page exists.

2

Hey @nekdolan,

Does this work in production? From what I know, RBAC is not supposed to have a to value. Plus, if you redirect everything, won’t it also affect the CSS/JS files, images, etc?

3

Hi it won’t affect JS, CSS because rewrite only happens if the file doesn’t exist.
Yes this works on production.

4

But how’s that secure? Rather, you’d specifically want to rewrite when the file exists as you want the content to be available behind the gate. The docs specifically ask you to force the rules.

5

Hey @nekdolan

This is similiar issue to another recent post Role Based Redirects causing an infinite loop

I suggested in that thread that this open CLI issue is possibly related. Possibly it is related here too? Your thoughts @hrishikesh?

6

Yes, I was going to come to that later and a workaround to use it regardless (which is possibly only available for Business and above plans). But at the initial stages, I still feel what @nekdolan is incorrect configuration and thus, I was trying to get that cleared out.

7

I’m not sure why it wouldn’t be secure. I have rule that forces away from /pro to /:splat (302). Are you saying that there is a way to reach pro content if I use a rewrite as opposed to a redirect?

This site has been statically generated via gulp with relative urls and the client wanted to have free and pro content preferably using the same urls. Not sure how else this could be possible. Using Ajax was not really feasible.

I understand that the docs suggests to use a redirect, but this as is works and it is really useful for the project at the moment.
@hrishikesh Should I assume that this feature will break in production in the near feature?

@coelmay we noticed some infinite loops in production, but we couldn’t reproduce it recently.

8

Could you share your entire netlify.toml as I don’t see that one in the snippet you shared.

9

Sure but as far as I remember the bug is caused by the rewrite

[build]
  publish = "dist"
  functions = "functions"
[dev]
  publish = "dist"
  functions = "functions"
[functions]
  node_bundler = "esbuild"
[[redirects]]
  from = "/pro/*"
  to = "/:splat"
  force = true
  status = 302
[[redirects]]
  from = "/free/*"
  to = "/:splat"
  force = true
  status = 302
[[redirects]]
  from = "/*"
  to = "/pro/:splat"
  status = 200
  conditions = {Role = ["pro"]}
[[redirects]]
  from = "/*"
  to = "/free/:splat"
  status = 200

I agree that if I didn’t have the redirect it would be unsecure. Thanks for the heads up.

10

As a side note:

That part is redundant and not required.

About your Role-based redirects, the setup looks really weird. That’s not how these redirects are supposed to be setup. You need to do the following:

[[redirects]]
  force = true
  from = "/pro/*"
  status = 200
  [redirects.conditions]
    Role = ["pro"]
[[redirects]]
  force = true
  from = "/pro/*"
  status = 302
  to = "/"

And same for free.

11

Changing these values did not fix the bug.
I think it should be fine either way. Some of the docs are using the other syntax:

Anyway I think we can treat this topic as a bug report and move on. Its not like this issue is blocking anyone.

14

Hey there, @nekdolan :wave:

I agree that we can treat this as a bug. You can file the issue directly on the CLI repo, linked here!

Thanks again for bringing this up!

15
17

This is interesting.

The documentation I have seen uses the former e.g.

 conditions = {Language = ["en","es"], Country = ["US"]}

I have seen [redirects.headers] mentioned in Netlify Docs, but not [redirects.conditions].

18

Hey @coelmay,

It’s just TOML syntax. Both the configurations mean the same thing (just like the previous JavaScript thread in which we talked about return {body} instead of return {body: body}).

So, in the above case,

You could write

[[redirects]]
# other stuff
  [redirects.conditions]
    Role = ["pro"]
    Language = ["en","es"]

# OR

[[redirects]]
# other stuff
  headers = {} # this syntax would be complicated for headers

###

# Works even for other stuff:

[build]
  [build.environment]

# the above is similar to:

[build]
  environment = {}
1 Like