跨域关系
假设我有 www.usa.com 作为主要网站。我将在具有相同托管的同一专用服务器上创建 www.utah.com..www.indiana.com...等。创建这些美国州网站后，我将从 www.usa.com 注册用户并将他们放置在不同的州下，并为他们提供自己的网站，例如 www.utah.com/andy 。此处，用户 Andy 是从 www.usa.com 注册的，但位于 www.utah.com 下。如果我从 www.utah.com 或 www.usa.com 搜索用户 Andy，我可以获取他的详细信息，但我无法从 www.indiana.com 获取他的详细信息。
我如何才能实现上述目标，例如从一个网站注册但放置在另一个网站中？您推荐一种数据库多域概念吗？我应该如何构建这种类型的应用程序？请帮忙
suppose I have www.usa.com as main site. I will create www.utah.com..www.indiana.com...etc on same dedicated server with same hosting. After creating those usa-state sites I will register users from www.usa.com and place them under different states and will give them their own site like www.utah.com/andy . Here user Andy was registered from www.usa.com but placed under www.utah.com. If I search user Andy from www.utah.com or www.usa.com i can get his details but i cant get his details from www.indiana.com.
how i can achieve the above like registered from one site but placed in another site? do u recommend one database-multiple domain concept? how should i approach to built this type of application? pls help
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
从您的描述来看，听起来更像是您的应用程序（作为单个应用程序）的逻辑组织如下：
usa.com
usa.com/犹他州
usa.com/utah/andy
usa.com/indiana
...
您可以通过一些 URL 重写为各州使用单独的域来实现您想要的。您的应用程序将处理搜索逻辑。
-或者-
另一种方法是将每个站点设置为其自己的应用程序。美国站点只需配置为搜索每个州站点（可能通过查询字符串）并聚合结果。
我知道还有其他方法可以设置您正在寻找的内容，但我认为这可能是两个主要的选择。
From your description it sounds more like your application (as a single app) would be logically organized like this:
usa.com
usa.com/utah
usa.com/utah/andy
usa.com/indiana
...
You could use separate domains for the states through some URL rewriting to achieve what you want. Your application would handle the search logic.
-OR-
The alternative is to setup each site as it's own application. The usa site would just be configured to search each of the state sites (via a query string maybe) and aggregate the results.
I know there are other ways to setup what you are looking for but I think these are probably the two major alternatives.