白标设计策略

发布于 2024-11-18 11:23:36 字数 634 浏览 1 评论 0原文

我有一个用 ASP.NET 编写的数据驱动网站。我已经让第三方联系我并询问我是否可以向他们自己的用户提供品牌访问权限。我认为这绝对是我想要的网站方向,但我不确定完成此任务的最佳方法。我希望获得有关实现此目的的各种方法的一些意见,以及每种方法的一些优点和缺点。

我希望尽可能减少第三方的技术负担。希望我能为他们提供一个 html 片段,这就是进行集成所需的全部内容。

以下是我想出的一些方法来实现这一目标。请评论每个人的智慧,并提供您认为可行的替代方案:

  • 为第 3 方创建一个子域。从服务器变量中读取它并相应地设置主题和数据。提供第 3 方网站管理员的链接。
  • 创建重定向页面,即 http://MywebApp.com/landingpage?ClientID=xxxx。页面将 xxxx 写入会话,然后用于设置主题和数据。与上面类似
  • 在第 3 方站点的 IFRAME 中工作。
  • 向第三方网站管理员提供 Javascript 代码,以便在其网站上动态生成源自我们服务器的内容。我什至不知道如何做到这一点,但我看到像 Disqus 和 facebook 这样的提供商使用这种方法。

I have a data driven web site written in asp.net. I've had 3rd parties contact me and ask if I could provide branded access to their own users. I think this is definitely the direction I want to take the site, but I'm unsure of the best way to get this done. I'm looking to get some input on various ways to implement this, and some pros and cons of each method.

I'm looking to put as little technical burden on the 3rd party as possible. Hopefully I can just provide them with an html snippet, and that would be all it takes to do the integration.

Here are a few ways I've come up with to make this happen. Please comment on the wisdom of each, and provide alternatives if you think they are viable:

  • Create a subdomain for the 3rd party. Read that from server variables and set theme and data accordingly. Provide a link to 3rd party web master.
  • Create a redirecting page i.e. http://MywebApp.com/landingpage?ClientID=xxxx. Page takes xxxx and writes into session, then that is used to set themes and data. Similar to above
  • Work within an IFRAME in the 3rd parties site.
  • Provider Javascript code to 3rd party's web master to dynamically generate content on their website, originating from our servers. I'm not even sure how to do this, but I see providers like Disqus and facebook use this approach.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

柏林苍穹下 2024-11-25 11:23:36

我现在面临着类似的选择,尽管需要客户顶级域(例如company.com)。我倾向于IFRAME,因为它提供了最大的可定制性(它们可以在他们想要的任何域上运行并构建内容) - 从小部件大小到整页),我们的工作量减少了。这种策略似乎对 Facebook 的画布和小部件都很有效。

I'm facing a similar choice now, although with the requirement of customer top level domain (e.g. company.com.) I'm leaning toward the IFRAME as it provides maximum customizability (they can run on whatever domain they want and frame the content - from widget sized to full page) and less work on our end. This strategy seems to work quite well for facebook both on canvas and for widgets.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文