Provider=None - redirects to a blank login screen?

Meshery
1

Hello,

Just giving Meshery a try this evening, I have deployed to my local Kubernetes Cluster via the CLI Curl call:

curl -L https://meshery.io/install | bash -

And select ‘kubernetes’.. everything seems to go great and I see my deployment running fine via my kubernetes-dashboard.

I then go to url for the UI and I am redirected to the ‘cloud.layer5. io’ login screen, where it asks me to create a login or use another provider (like Google).

For evaluation purposes I would like to only work locally for the time being, and I see there is a ‘None’ provider which does just that.

However, I never get presented with a login screen that lets me select a provider, this interface is shown a few times in the documentation however? A page with a Provider Pull-down? The default install always redirects me straight to the layer5 site/login page?

I see that the provider can be set via the CLI. So I switch to the local ‘None’ provider, following these steps:

mesheryctl system login
mesheryctl system status
mesheryctl system provider list
mesheryctl system provider set None
mesheryctl system stop
mesheryctl system start

And upon clearing my browser cache (so I dont get redirected to cloud.layer5. io) I am instead taken to the local UI URL ending in:

/user/login?

And presented with a blank white webpage?

It is my understanding, based upon the description in the documentation (here) that I should instead simply be taken into the local UI and be presented with the same interface I would otherwise see..

I again confirm my provider is set to Local / None via the CLI:

mesheryctl system provider view
Context: local
Provider: None

Is there something else I am missing? Something in the logs?

Here is my version information:

mesheryctl version

VERSION GITSHA
Client v0.8.200 e541c782458
Server v0.8.200 e541c782
Checking for latest version of mesheryctl…

v0.8.200 is the latest release.

Thanks.

Neal

2

What an excellent write up, @Neal. You’ve accurately described the system behavior and from what I garner based on the steps that you’ve taken, this smells like a bug. Above all other providers, the local provider “None”, should be perpetually available in the Meshery-published distro. While there are a number of distributions of Meshery that take advantage of build-time environment variables to pre-select a provider (in large part for security reasons), the distro that you get when invoking the commands that you’ve listed above most certainly offers the built-in, local provider.

And presented with a blank white webpage?

We’ll be investigating this behavior promptly.

3

Thank you for the quick reply, @Lee.

Please let me know if there is anything else I can help provide (screenshots, logs, testing fixes, etc).

In the meantime, it looks like the install script supports:

MESHERY_VERSION

The latest rev is v0.8.200

Perchance do you know when the bug was introduced (or the last minor rev it was for-sure working?) ..and I can give it a go with a re-install on an older version…

Neal

1 Like
4

Hi @Neal do you have a kubernetes cluster up and running ? Also have some output of the cli will help us identify the issue.

Perhaps trying using docker provider for evaluation can be an option

mesheryctl system start -p docker
2 Likes
5

Reading through @Neal’s messages… @Neal is awesome. :heart:

I was able to reproduce the behavior just now, using docker as the platform. I opened Present Provider causes blank login screen · Issue #17087 · meshery/meshery · GitHub.

2 Likes
6

Great questions. Thank you for being truly helpful, @Neal. :handshake: Immediately, I can say two things:

  1. It’s non-obvious (and we need to enhance docs and the UX of the CLI to clarify) that the primary purpose of the mesheryctl system provider command that controls the provider: [local|remote] property in your mesheryctl system context (your meshconfig as we colloquially put it) is that of preselection of a provider, which has the effect of both foregoing the initial provider selection screen, and importantly, is intended to have the effect of enabling one and only one provider.

The first bit of behavioral note explains why you’re not seeing the provider selection (drop-down list) that you’re expecting to see. This second bit of this note highlights the critical nature of provider preselection in context of system security such that you’re able to control which identity providers are allowed/disallowed for any given Meshery deployment.

  1. An immediate workaround using v0.8.200 is to use your favorite text editor, opening ~/.meshery/config.yaml, delete the provider line in the context that you’re using, save, and execute a mesheryctl system restart. You should subsequently be presented with the provider selection screen.

Having said this, and having just performed these steps, it behooves me to be forthright and highlight that I readily spot a couple of bugs upon choosing the local “None” provider (e.g. message “Error fetching user” - harmless, but annoying). This provider is lesser used, consequently, it receives less attention. With that said, it is of no less importance. We’ll document these bugs and get fixes out pronto.

1 Like
7

Thanks for being Johnny on the spot, @Matthieu.EVRIN and @Cooper!

8

Hi @Matthieu.EVRIN ,

I’m running a 5-node cluster on the following version:

kubectl version
Client Version: v1.33.5+k3s1
Kustomize Version: v5.6.0
Server Version: v1.33.5+k3s1

Looks like @cooper in the next message down in the thread was able to reproduce on docker as well.

FWIW I started to look back through the releases and release notes, to see if there were any items fixed/addressed related to ‘providers’… a couple of pull requests/merges caught my eye, although admittedly this is the first time looking at the code base, so I’m still lost.. there is a lot of ‘branding’ cosmetic changes but also some bug-fixes with logins/redirect loops? ..so I will mention them now:

  • 16788
  • 16755
  • 16732

This is in the 0.8.194 to 0.8.195 timeframe.

I’m not laying any blame here, just noting, based on my experience, where I might start looking for recent changes… again, this is my first time looking at this project..

Thanks,
Neal

1 Like
9

@Lee I took a quick look at the last few releases and release notes, looking for anything ‘provider’ related… and mentioned a few pulls in my reply to @Matthieu.EVRIN & @ cooper that (to me) would be places I might go and look to see if the bug was introduced there…

Disclaimer: I’m still wet behind the ears on this codebase, just sharing my intuition from 30yrs of bug-making/fixing.. :wink:

10

30 years of procreating and smashing bugs… intuition refined. Layer upon layer of wisdom flowing from fingertip to keyboard… yes, I can almost hear the clickety-clack of those keystrokes now.

Thank you very much for having a quick poke around the codebase. Please know that you are most encouraged to dive into any and all aspects of the projects here. The water is warm. The jokes are corny. The metaphors are stretched thin.

Your kindness in not insinuating blame is appreciated. On the other side of that coin, please, please, please call our baby (your future baby?) ugly any and every time you spot a blemish (bug). Meshery’s v1.0 release draws near. Hardening and tightening so very much needed.

1 Like
11

@Lee a bit more follow-up:

I nuked the ‘provider’ line from my ~/.meshery/config.yaml (after first making a backup copy) and performed the restart:

mesheryctl system restart
Meshery deployments will be deleted from your cluster. Are you sure you want to continue [y/n]? y
Restarting Meshery…
Stopping Meshery resources…
Deleting Meshery Namespace…
Meshery resources are stopped.

Meshery deployed on Kubernetes.
Meshery is starting…
Short Description: Unable to discover an endpoint

..and the subsequent check looks good:

mesheryctl system check

Kubernetes API

✓ can initialize Kubernetes client
✓ can query the Kubernetes API

Kubernetes Version

✓ running the minimum Kubernetes version
✓ running the minimum kubectl version

Meshery Version

✓ Meshery Server is up-to-date (stable-v0.8.200)
✓ CLI is up-to-date (stable-v0.8.200)

Meshery Components

  • No components configured in current context

Meshery Operators

✓ Meshery Operator is running
✓ Meshsync is running
✓ Meshery Broker is running
✓ Meshery Broker CR contains Status.Endpoint (External: xxx.xxx.xxx.xxx:4222, Internal: yyy.yyy.yyy.yyy:4222)

..looking at the provider view:

mesheryctl system provider view
Context: local
Provider:

After a short wait **, I was able to access the UI URL again, it briefly brought up a intermediate screen but there was no selection/pulldown.. and then redirected me to the expected User Interface! :partying_face:

One last note on my restart at the very end:

Meshery is starting…
Short Description: Unable to discover an endpoint

..I think this is in part due to the responsiveness of my kube cluster.. it takes a hot minute to stand up all the containers and plumbing across the 5 underspec’d machines in my homelab…

I think this is also in part due to the healthchecks and how I have my proxy setup.. I’m using Zoraxy to get back through my kube cluster host ips to access the port-mapped containers..

Zoraxy → (round robin LB) to (5) Kube Host IPs → (5) containers w/ UI → Wholesome Meshery Goodness

I’ve got a watch on the Issue @cooper created, so I’ll see any code changes that come across and get to learn a bit more about how it all works.

Neal

1 Like
12

Are you using kind ?

In your cluster what is the status of meshery server ?

15

@Neal a fix has been released in Meshery v0.8.201 and another in v0.8.202. :+1: To deploy this latest version (v0.8.202), you should only need to execute mesheryctl system start. Just in case this doesn’t do the trick (depending upon your current configuration), you might execute mesheryctl system update or edit the version listed in your meshconfig file (~/.meshery/config.yaml). Please let us know if this fix gets you back in gear and moving along again with the local provider. :+1:

1 Like
16

Thank you @Lee will pull down the latest and give it a go.

17

Hmn I must be missing something @lee.

This time I did a fresh install on a system running Docker [Option #2] - no previous meshery install:

curl -L https://meshery.io/install | PLATFORM=docker MESHERY_VERSION=v0.8.202 bash -

..the install script checks for version also notes that v0.8.202 is the latest, so passing that env var in might be redundant in my case..

Install proceeds fine and the docker container(s) kick off fine..

Then I portmap so I can access the UI, but then I still get 302/303’d redirect again to the cloud site:

https://cloud.layer5.io/login?flow=xxxxxxx

Screenshot 2026-02-04 122335
Screenshot 2026-02-04 122335799×193 15.5 KB

On the CLI when I perform:

mesheryctl system login

..I can select Layer5 or None.. I choose none and the stop/restart.

Also ran the Provider selection (list then set) to None..

Still the redirect to the cloud login page – no choice to select Layer5 or None in the Web GUI?

In an incognito window if I access the UI URL I get stuck on a blank white page when it redirects me to /user/login? Same if I change the dns entry for the UI to be something it hasn’t cached the redirect on.

If I remove that /user/login? and/or attempt to go to the main UI URL again then I the expected UI..

Web Browser is Chome v 144.0.7559.132 on Windows 11.. FWIW

18

Oof. Our apologies, @Neal. A couple of contributors have been working on a fix, which is due to be released tomorrow. :+1: Thank you much for sticking with this and seeing it through.

1 Like
19

Hi @Neal, thanks for sticking with this and for the continued follow ups.

This issue is now fixed in the latest Meshery release v0.8.205. With this update, selecting the None provider no longer redirects to a blank login screen and instead opens the Meshery UI as expected.

To ensure the fix takes effect properly, could you please try a clean reinstall of Meshery? In some cases, existing state or cached configuration from older versions can interfere with the update.

Once reinstalled, it would be great to know if the behavior is fully resolved on your end.