跨域的 PHP 共享会话

发布于 2024-08-30 05:34:34 字数 987 浏览 3 评论 0原文

我在 SOF 上看到了一些对此问题的答案,但其中大多数都与子域的使用有关,其中没有一个对我有用。常见的一个是使用 session.cookie_domain,据我了解,它仅适用于子域。

我对处理完全不同的域(并包括子域的可能性)的解决方案感兴趣。不幸的是,项目截止日期已定,时间不在我这边,所以我求助于 SOF 的专业知识和经验。

当前的项目简介是能够登录一个当前仅在会话中存储 user_id 的站点,然后能够在同一服务器环境中的不同域上检索该值。会话数据是从数据库中存储/检索的,其中会话 ID 是主键。

我希望找到一个“轻量级”且“易于”实施的解决方案。

该系统使用内部模型视图控制器设计模式,因此所有请求(包括不同的域)都通过单个引导脚本运行。使用域名作为变量,这决定了向用户显示什么上下文。

看起来确实有潜力的一种选择是使用隐藏图像并使用 alt 标签来设置用户 ID。我的第一印象表明这似乎“太容易了”(如果可能的话)并且充满了安全缺陷。讨论?

我考虑的另一个选择是使用 IP 和用户代理进行身份验证,但由于共享网络和不断变化的 IP 地址,我再次认为这不是一个可靠的选择。

我考虑过但尚未讨论的第三个选项(也是首选)是使用 htaccess 来欺骗用户,让他们认为他们在不同的域上,而事实上 apache 正在重定向;类似

www.foo.com/index.php?domain=bar.com&controller=news/categoires/1
但向用户显示为
www.bar.com/news/categories/1

foo.com 表示所有请求都通过的“主站点域”,bar.com code> 是用户认为他们正在访问的内容。控制器请求指示所请求的页面和视图。这可能吗?

还有其他选择吗?优点/缺点?

提前致谢!!!

I have seen a few answers to this on SOF but most of these are concerned with the use of subdomains, of which none have worked for me. The common one being that the use of session.cookie_domain, which from my understanding will only work with subdomains.

I am interested in a solution that deals with deals with entirely different domains (and includes the possibility of subdomains). Unfortunately project deadlines being what they are, time is not on my side, so I turn to SOF's expertise and experience.

The current project brief is to be able to log into one site which currently only stores the user_id in the session and then be able to retrieve this value while on a different domain within the same server enviroment. Session data is being stored/retrieved from a database where the session id is the primary key.

I am hoping to find a "light wieght" and "easy" to implement solution.

The system is utlising an in-house Model View Controller design pattern, so all requests (including different domains) are run through a single bootstrap script. Using the domain name as a variable, this determines what context to display to the user.

One option that did look like to have potential is the use of a hidden image and using the alt tag to set the user id. My first impressions suggest this immediately seems "too easy" (if possible) and riddled with security flaws. Disscuss?

Another option which I considered is using the IP and User Agent for authentication but again I feel this not going to be a reliable option due to shared networks and changing IP addresses.

My third option (and preferred) which I considered and as yet not seen discussed is using htaccess to fool the user into thinking that they are on a different domain when infact apache is redirecting; something like

www.foo.com/index.php?domain=bar.com&controller=news/categoires/1
but displays to the user as
www.bar.com/news/categories/1

foo.com represents the "main site domain" which all requests are run through and bar.com is what the user thinks they are accessing. The controller request dictates the page and view being requested. Is this possible?

Are there other options? Pros/Cons?

Thanks in advance!!!

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

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

发布评论

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

评论(3

如果没结果 2024-09-06 05:34:34

您是否考虑过使用session_set_save_handler。您可以将会话存储在数据库中并从任何域访问它们。

Have you thought about using session_set_save_handler. You can store your sessions in a database and access them from any domain.

猫七 2024-09-06 05:34:34
  1. 定义一个主会话服务器(我与 memcached 结合使用)

  2. 使用 Ajax / JSON(P) 请求会话此服务器,这允许您在多个域上共享会话

  3. 重用此会话

  1. Define a main session server (I do this in combination with memcached)

  2. use Ajax / JSON(P) to request a session from this server, this allows you to share sessions over multiple domains

  3. Reuse this session

夜雨飘雪 2024-09-06 05:34:34

为了让其他对此功能感兴趣的人受益,恐怕没有简单的答案。谷歌“单点登录”,它将带着技术和一些可用的解决方案回来。

至于使用htaccess来隐藏域名,这是不可能的,因为它可能被用于恶意活动。

我现在已经成功实现了一个系统来满足我的要求。

For the benefit for anyone else interested in this functionality, there is no simple answer I am afraid. Google "Single Sign On" and it will come back with the technology and some solutions avialable.

As for using htaccess to hide the domain name, this is not possible as it could be used for malicious activities.

I have now successfully implemented a system to achive my requirements.

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