替换全局变量,如何以及为什么
好的,到目前为止我已经工作并使用了全局变量,并且仅调用 $USER 来获取用户 ID 没有问题。
大多数时候,人们对 SO 的看法以及一些到处阅读的文章都对使用全局变量持负面态度。
所以现在我准备改变方式而不是使用全局变量。
现在我包含一个函数,protect(),它检查您的会话并创建全局变量,例如 $USER、$USERTYPE 。
然后我可以在文件中尽可能多地使用这些变量。
什么可以替代这个?我想过制作 $USER = scrapUserid();这将返回用户 ID,对于用户类型也是如此,这已经是 2 个函数了,那么我需要为每个变量创建带有数据库查询的函数吗?
那么我的 $connect 呢,它是数据库的 PDO 对象,处理我所有的查询,我需要执行 $connect = connectdb();那么
使用js到另一个php文件的http请求呢,我需要传递它,但是在它们之间它可能是不安全的(如果你考虑到安全性),因为你可以操纵它们之间的用户id..
或者也许有这样做的第三种解决方案?或者我应该坚持全局?一劳永逸地请提及为什么全局变量如此糟糕?是安全吗?还是肮脏编码的样子?
Ok so I have worked and used my global variables until now, and it has been no problem in just calling $USER to get the user id.
Most times from people on SO and some reading here and there, it all has been so negative towards using the global var.
So now i am ready to change the way and not using global variables.
Right now i include a function, protect() which checks your session and makes the global variables such as $USER, $USERTYPE .
And then i can just use these variables as much as i want in the file.
What can replace this? I have thought of making $USER = grabUserid(); that will return the user id, and same for the user type, thats already 2 functions and i would need to make function with database queries for every variable then?
And what about my $connect, which is a PDO object for the database, handling all my queries, i would need to do $connect = connectdb(); too
And what about http requests with js to another php file, i would need to pass it, but then between there it can be unsafe (if you think of security) as you can just manipulate the user id between there..
Or maybe theres a third solution of doing this? Or should i just stick to the globals? And once and for all please mention why globals vars are so bad? is it security? or the look of dirty coding?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
发布评论
评论(2)
您将需要利用会话和会话变量。
会话允许 php 为每个当前用户创建唯一的标识符。通过识别每个单独的用户,php 可以创建特定于该会话的变量。
例如,您可能会创建会话变量,如 $Session["memberID"]、$Session["last_page_visited"] 等...这样做的好处是每个会话只能访问自己的变量,而其他人不能访问。
此外,会话本身将在设定的时间段后超时。这将清除与此会话关联的所有变量。这就是为什么使用全局变量有点糟糕。
- 全局变量会带来意想不到的结果。你不知道变量来自哪里,也不知道谁最后接触了它。
- 由于存在全局范围,因此安全性是
- 内存使用的一个问题。如果使用全局变量来存储大量信息,因为没有数据可以长期保留的范围。我不确定全局变量何时被清理(如果有的话)。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
所以这个问题实际上是两个问题:为什么我要停止使用全局变量,以及我应该如何使用另一个构造来实现类似的功能。
首先,为什么您可能想停止使用全局变量:
我想说的是,不使用全局变量与其说是规则,不如说是指导方针。虽然这个问题的双方都有狂热分子,但也有一些充分的理由支持和反对(尽管我听到的反对多于支持)。您可能希望避免全局变量的一些原因:
访问控制
这可能是不使用全局变量的最大和最坚实的原因。通过全局变量构造,任何代码都可以以任何方式使用存储在变量中的数据,无论范围或原因如何。鲁莽的写入可能会破坏访问规则并使数据无效。未经验证的访问意味着数据不可信。
并发
如果您有一个全局变量,根据定义它没有显式的访问规则,那么并发性可能是一个真正的问题。如果两个同时运行的实例或函数正在访问相同的数据,则无法保证读取或写入发生的顺序 - 进一步污染您的数据。
耦合/结构/代码清晰度
简而言之,当您在 OOPHP 中使用全局变量时,您可能正在以更直接的方式编码来传递数据。使用全局变量编写意味着使用该数据的过程之间的紧密耦合,并且使得理解数据流变得困难。在大多数情况下,重构几乎是必要的。
第二,如何避免全局变量:
静态变量/对象
避免全局变量的最佳方法之一是将“全局”数据包装在静态对象中。这允许您围绕数据创建 getter 和 setter 的代码安全性达到最低水平,这些数据可以进行绑定检查、访问限制,或者至少根据需要数据锁定全局变量。这可能需要一些额外的编码,但是您获得的数据安全级别是值得的。
重构
考虑一下您使用全球数据的原因。您是否只是想绕过在函数之间传递数据?您是否正在尝试创建可由 $Session 轻松(且更有效)处理的持久数据?通常,全局变量是快速轻松配置或会话工作的权宜之计。使用配置文件或会话可以增加一定程度的功能、可扩展性和安全性,这通常值得付出额外的工作。
在某些情况下全局变量会很有用。在非常的程序中,数据安全性完全不相关,或者数据在整个代码中真正使用,没有良好明确的方法来传递它或避免范围问题,使用全局变量可能是可以的,但总的来说,它们是不好的做法。
思考这个问题的一个好方法是“如果我的全局数据变成垃圾,我的脚本会发生什么”。如果答案不是“真的不多”,那么您可能应该找到一种方法来保护该数据或重新考虑使用它的方式。
So this question is really two questions: why would I stop using global vars, and how should I implement similar functionality with another construct.
First, why you might want to stop using global vars:
Let me say that not using global variables is not a rule so much as a guideline. While there are zealots on both sides of the issue, there are some good reasons for and against it (though I've heard more against than for). Some reasons you might want to avoid global variables:
Access control
This is probably the biggest and most solid reason for not using globals. With the global variable construct, any code can use the data stored in the variable any way it wants regardless of scope or reason. Access rules can be broken and the data can be invalidated by a reckless write. Unverified access means untrustworthy data.
Concurrency
If you have a global variable, which by definition have no explicit access rules, concurrency can be a real issue. If two concurrently running instances or functions are accessing that same data, there is no way to guarantee the order in which reads or writes happen - further polluting your data.
Coupling/Structure/Code Clarity
Simply put, when you're using global vars in OOPHP, it's likely you're coding your way around passing your data in a more direct way. Writing with globals implies tight coupling between the procedures using that data, as well as makes it difficult to understand the data flow. Refactoring is almost a necessity in most cases.
Second, how you can avoid global vars:
Static Vars/Objects
One of the best ways to avoid globals is to wrap your "global" data in a static object. This allows you the minimum level of code safety of creating getters and setters around the data that can either bound check, access restrict, or at the least data lock your global variables as necessary. It may be a bit extra coding, but the level of data security you gain is worth it.
Refactor
Think about the reason you're using your global data. Are you just trying to get around passing that data between functions? Are you trying to create persistent data that could be just as easily (and more effectively) be handled by $Session ? Often globals are stopgaps for quick and easy configurations or session work. Using config files or sessions add a level of functionality, extensibility, and security that is often worth the extra work.
There are a few cases where globals can be useful. In very small programs, where data security is entirely irrelevant, or where your data is TRULY used throughout the code with no good clear way of passing it or avoiding scope issues, it may be alright to use global vars, but in general they're bad practice.
A good way to think about it is "what would happen to my script if my global data turned out to be garbage." If the answer is anything but "not much, really," then you should probably find a way to protect that data or to rethink the way you're using it.