快速 JS 路由

Question

Beginner question here. I'm wanting to build an app that will be an intranet of sorts for a 70 unit restaurant chain. What I'm needing is for each physical restaurant location to see data posted to a MongoDB DB and show on a page in the store within a screen hanging on the wall. This data will be specific to each location such as announcements, catering orders that need to be filled by that store, etc... my question is, how do I create routes so that each individual store will see only their data without having to create 70 different routes or use authentication to utilize user IDs?

Trying to avoid user logins and:

“/store1” “/store2” “/store3” Etc...

Seems like I could query a site ID or something like that

Hope this make since.

Answer 1

If you're talking about one centrally located server that is accessed by all 70 restaurants and you want to have the same routes for all, then you need to decipher some other clue from the request to figure out which restaurant it is that is making the request.

Since you have nixed authentication, I will assume that there are no security concerns here - that this is on an intranet only accessible by restaurant employees.

So, here are the clues you could get from any given request to decide which restaurant's data to show:

1. Cookie that contains desired restaurant ID.
2. Query parameter that contains desired restaurant ID.
3. IP address of request to discern which restaurant the request is coming from.
4. Separate sub-domain for each restaurant (all pointing to the same host).

Here's more info on each option:

Cookie

In this implementation, if a client arrives with no cookie set for the restaurant ID, then you take them to an opening page where they select which restaurant they want to see the data for and you ask the user to manually select the desired restaurant. Then, you set a long lasting cookie in that browser and from then on (as long as the cookie is not removed), your server can default to showing them info only for their restaurant.

Query Parameter

In this implementation, you use some initial restaurant specification like in the cookie option and then you generate pages where all the links have a query parameter specified in them that lists the restaurant ID (likely using a template system). This is generally not favored these days over a plain cookie system.

IP address

If all your restaurants have their own sub-network (presumably some sort of broadband connection connecting to a central server over some sort of private connection, then you could perhaps build a small table of restaurant source IP addresses so you could identify which restaurant was making the request purely by the IP address of the request. This may or may not be feasible depending upon your network topology. This would be much more automatic than any of the other options.

Separate sub-domain

This would work somewhat like the cookie-based option, but instead of setting a cookie, once the desired restaurant was selected, you would redirect to a subdomain specific to that restaurant. All sub-domains would still point to the same host, but the host could identify the desired restaurant from the sub-domain making the request. Similar to the query parameter option, you'd some template system on the server side to rewrite all links to include the proper sub-domain so you'd stay on the same sub-domain as you navigate.

---

Of all of these options, the IP address scheme is the only one that would be completely automatic, but may or may not be feasible depending upon your network topology. Of the other choices, the cookie is the most straightforward to implement because the page links themselves don't have to be rewritten.

---

Enterprise Configuration

In an enterprise scenario where you "manage" any browser that is approved for use, you may also be able to pre-configure the browser in each restaurant to automatically provide some identification (either a custom header or a cookie) and your server could use that identification info to determine which restaurant was making the choice. This would require accessing your site only through pre-configured and approved and properly maintained browsers (which may be more pain than it's worth).

For example, here's how you would configure a custom header on all requests with Microsoft Edge .