Inconsistent GUI rendering when accessing Kedro pipeline via localhost vs device IP

[kravitsjacob]

Description/Context

I am currently hosting a kedro viz instance on my local machine (for example, local ip address of 192.168.0.9) on a specified port, for this example let's say port 1234.

So, if I go to localhost:1234 I get a "complete" kedro visualization:

I want to quickly share this visualization with my coworker on my network. I expose that port, and direct them to `192.168.0.9:1234'. However, when they visit, they get an "incomplete" kedro visualization that is missing the experiments tab, among other things:

Interestingly, if I direct them to the experiments page directly 192.168.0.7:1008/experiment-tracking, the page does work and they are able to access the experiments page. So, this appears to just be a GUI problem (Cross-Origin Resource Sharing?!?).

I acknowledge that there are better ways of sharing these dashboards, but give my current development needs, I want to be able to quickly share the dashboard running on my machine with coworkers on my network.

Steps to Reproduce

1. Host a kedro instance on a specified port kedro viz run --host=0.0.0.0 --port=1008
2. Ensure that port is exposed
3. Visit localhost:1234 and note that the full dashboard is hosted, as expected.
4. Visit <your-local-ip>:1234

Expected Result

<your-local-ip>:1234 should be exactly the same as the localhost:1234 version.

Actual Result

<your-local-ip>:1234 is missing certain functionality, for example the experiments button, when compared to the localhost:1234 version.

Environment

• Web browser system and version: Tested on Chrome and Edge
• Operating system and version: Windows 11 Pro 22631.4460
• Kedro version used (if relevant): v0.19.9
• Plugins: kedro_telemetry: 0.6.1 (entry points:cli_hooks,hooks), kedro_viz: 10.0.0 (entry points:global,hooks,line_magic)
• Python version used (if relevant): Python 3.11.9

Thank you in advance for your help! I've only been using kedro a few hours, so my apologies if this is basic question!

[tynandebold]

It isn't a CORS issue. It's because there's a function that checks if the URL is deemed to be running locally, which then changes some elements of the UI. This is the code:

kedro-viz/src/utils/index.js

Lines 194 to 207 in eac8d39

	export const isRunningLocally = () => {
	const hosts = [
	'localhost',
	'127.0.0.1',
	'demo.kedro.org',
	'gitpod',
	'kedro-org',
	];
	const itemFound = hosts.some((host) =>
	window.location.hostname.includes(host)
	);
	return itemFound;
	};

If your 192.168.0.9:1234 address was included there, you'd see what you'd expect to see.

[kravitsjacob]

Thank you for the quick response! I'm glad to hear it's not a CORS issue-those can be trickier to deal with!

Is there currently a more polished way to add a custom host to this list? If not, do you think it might be worth exploring a way to make this process more flexible? For instance, allowing users to configure their own addresses or perhaps reconsidering the assumption that these UI elements are only relevant for local environments. I'd potentially be happy to help contribute if this is something worth pursuing!

[SajidAlamQB]

I agree this is inconsistent, we could do several things here.

Option 1: Cover the standard private IP address ranges defined in RFC 1918 this should cover the 192.168.X.X subnet.

Option 2: We consider allowing users to define what they consider 'local' via configuration options:

• Env variables: Allow users to specify additional hosts or IP ranges via an environment variable like KEDRO_VIZ_LOCAL_HOSTS.
• CLI: Introduce a CLI flag such as --local-hosts that accepts a list of hosts.

@astrojuanlu @Huongg what are your thoughts?

[astrojuanlu]

I'm curious, any reason why the UI looks different depending on isRunningLocally? @stephkaiser

[Huongg]

Hey @astrojuanlu , if I recall correctly, we agreed not to display the Experiment Tracking tab or features like the Shareable Viz button in published environments that aren’t "considered" as runningLocally. Experiment tracking was intended for future versions of Shareable Viz, but we haven’t gotten around to implementing it yet.

This scenario is a bit of an edge case since it’s not hosted on a cloud platform, but it’s also not the typical localhost setup we usually deal with.

So, @SajidAlamQB, I’d lean towards option 1, as it’s the simplest solution—especially since we’re planning to deprecate the Experiment Tracking feature anyway.