当 URL 中存在查询字符串时，SharedObject (Flex 3.2) 表现异常
摘要：下面详述的行为似乎表明，如果您的应用程序在 www.someplace.com 通过 SharedObject 设置/检索数据，则当用户在某个地方点击您的应用程序时，会出现某种 .sol 冲突.com，然后是 someplace.com？name=value。
谁能证实或反驳这一点？
我正在开发一个 Flex Web 应用程序，该应用程序向用户显示登录页面。 当用户登录时，他/她会看到一个与“组”关联的“房间”。
我们将上次访问的房间/组组合存储在 SharedObject 中 - 因此，当给定用户登录时，他们会被带入他们最近活动的房间。
这工作正常，但我们还有一个自动登录系统，其中涉及用户单击附加查询字符串的应用程序 URL 的链接。 这些链接有两种类型。
1) 查询字符串包括用户名、groupId 和 roomId
2) 查询字符串仅包括用户名
由于我们工作速度很快且开发人员很少，所以自动登录系统是在上次访问系统上构建的。 在自动登录过程中，会检查 url，如果在查询字符串中找到 groupId 和 roomId 值，则打开 SharedObject，并且最后访问的组/房间 id 值将被参数值覆盖。
这也很好用，当应用程序遇到第二种类型的查询字符串（没有 groupId 和 roomId 参数）时，应用程序会像平常一样转到 SharedObject 来获取存储的房间和组 id 值。 问题是：
它返回的值是最后一个房间/组参数值，而不是最后一次访问的房间/组值。
如果给定用户从未使用包含组和房间 ID 值的查询字符串访问应用程序，则应用程序将从 SharedObject 获取空值。
我们花了一些时间进行挖掘，但看起来正在发生的是，如果 URL 中存在查询字符串，则第二组数据将存储/预期在 SharedObject 中。
当我使用包含查询字符串的 URL 访问应用程序时，在文本编辑器中查看 .sol 文件，我会看到更多未翻译的代码以及其他组和房间值。
我在网上没有找到任何与此相关的信息，但这可能只是由于缺乏必要的搜索技能。
还有其他人遇到过类似的事情吗？ 或者你知道如何解决这个问题吗？
我已经尝试将 Security.exactSettings 设置为 false - 真的希望这会起作用。
Summary: The behavior detailed below seems to indicate that if your app at www.someplace.com sets/retrieves data via a SharedObject, there is some sort of .sol collision if the user hits your app at someplace.com, and then later at someplace.com?name=value.
Can anyone confirm or refute this?
I'm working on a Flex web app that presents the user with a login page. When the user has logged in, he/she is presented with a 'room' which is associated with a 'group'.
We store the last-visited room/group combination in a SharedObject - so when a given user logs in, they are taken into the most recent room in which they were active.
That works fine, but we also have an auto-login system which involves the user clicking on a link to the app url with a query string attached. There are two types of these links.
1) the query string includes username, groupId, and roomId
2) the query string includes only the username
Because we are working fast and have only a few developers, the auto-login system is built on the last-vist system. During the auto-login process, the url is inspected and if groupId and roomId values are found in the query string, the SharedObject is opened and the last-visit group/room id values are overwritten by the param values.
That works fine, also, when the app is hit with a query string of the second type (no groupId and roomId params), the app goes to the SharedObject to get the stored room and group id values, as it normally would. And here's the problem:
The values it comes back with are whatever the last room/group param values were, not whatever the last last-visit room/group values are.
And if the given user has never hit the app with query string that included group and room id values, the app gets null values from the SharedObject.
It took some digging around, but what it looks like is happening is that a second set of data is being stored/expected in the SharedObject if a query string is present in the URL.
Looking at the .sol file in a text editor I see more untranslated code, and additional group and room values, once I've hit the app with URLs that contain query strings.
I'm not finding anything on the web about this, but that may just be due to a lack of necessary search skills.
Has anyone else run into anything similar? Or do you know how to address this?
I've tried setting Security.exactSettings to false, already - was really hoping that was going to work.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
要记住一件事：
- 它们是共享的 - 但有延迟。 如果您获取共享对象并对其进行更改，则更改将在延迟后写入客户端 .sol。
另外，我注意到对于某些客户端（尤其是 Vista），在应用程序状态早期访问 ShraedObjects 会引发异常。 如果稍后再尝试，通常会成功。
One thing to remember:
- They are shared - but with a delay. If you get a shared object and make a change to it, the changes will be written to the client .sol - after a delay.
Also, I have noticed that for some clients (especially Vista), accessing ShraedObjects early in the app state throws an exception. If you try again a bit later, it usually succeeds.
听起来您在登录过程中正确写入了共享对象，但当用户在使用应用程序时更改房间/组时，没有正确地将房间/组写入共享对象。
这就是为什么如果他们从未使用房间/组参数访问应用程序，这些值将为空，以及为什么这些值不反映登录过程后发生的更改。
另外，为了确保写入值后将其保存到磁盘，您可以调用 mySharedObject.flush()。
It sounds like youre correctly writing to the shared object during the login process, but not writing the room/group to the shared object correctly when a user changes rooms/groups while using the app.
Thats why the values would be null if they had never gotten to the app with the room/group params and why the values arent reflecting changes that occur after the login process.
Also to make sure the values get saved to disk after you write them you can call
mySharedObject.flush().