blocks|key|279085|text|它们都是很好的方法，使用MySQL也有一些缺点，在某些情况下，如果操作不当或负载太高，流量级别实际上可能会导致服务器崩溃！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|279086|我个人建议，考虑到标准会话已经得到了适当的处理，只使用它们并加密了你不想让黑客看到的数据。|279087|没有适当的预防措施，使用cookies是不安全的。除非您需要“记住我”，否则请继续使用会话！:)|279088|编辑|279089|不要使用MD5，它的加密和解密能力都很差。我建议对数据进行盐化，并将其全部加密。|279090|$salt+=+'dsasda90742308408324708324832';
$password+=+sha1(sha1(md5('username').md5($salt));|code-block|syntax|javascript|279091|这种加密不会很快被解密，我认为到目前为止这是不可能的。|279092|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|U|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|V|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|W|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|X|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|Y|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

They are both great methods, there are some downsides to using MySQL which would be traffic levels in some cases could actually crash a server if done incorrectly or the load is just too high!

I recommend personally given that standard sessions are already handled properly to just use them and encrypted the data you do not want the hackers to see.

cookies are not safe to use without proper precaution. Unless you need "Remember me" then stick with sessions! :)

EDIT

Do not use MD5, it's poor encryption and decryptable... I recommend salting the data and encrypting it all together.

<pre><code>$salt = 'dsasda90742308408324708324832';
$password = sha1(sha1(md5('username').md5($salt));
</code></pre>

This encryption will not be decrypted anytime soon, I would considered it impossible as of now.

blocks|key|277351|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|277352|应用程序会在请求之间丢失会话信息。由于斯坦福有多个web服务器，不同的请求可能会被定向到不同的服务器，因此会话信息通常会丢失。|blockquote|277353|277354|斯坦福大学的web基础设施由多个web服务器组成，这些服务器彼此之间不共享会话数据。因此，会话可能会在两次请求之间丢失。使用MySQL有效地解决了这个问题，因为所有会话数据都被定向到数据库服务器，而不是web集群。在数据库中存储会话还具有增加私密性和安全性的效果，因为访问数据库需要身份验证。我们建议斯坦福大学所有有权访问MySQL的web开发人员都使用这种方法来处理会话。|277355|277356|引用自http://www.stanford.edu/dept/its/communications/webservices/wiki/index.php/How_to_use_MySQL-based_sessions|offset|length|277357|This可能会对您有所帮助。|277358|entityMap|0|LINK|mutability|MUTABLE|url|http://www.stanford.edu/dept/its/communications/webservices/wiki/index.php/How_to_use_MySQL-based_sessions|1|https://stackoverflow.com/questions/2316478/php-session-vs-mysql-speed^0|0|0|0|0|0|3|2Y|0|0|0|4|1|0^^$0|@$1|2|3|-4|4|5|6|X|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|Y|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|Z|7|@]|8|@]|9|$]]|$1|E|3|F|4|5|6|10|7|@]|8|@]|9|$]]|$1|G|3|-4|4|5|6|11|7|@]|8|@]|9|$]]|$1|H|3|I|4|5|6|12|7|@]|8|@$J|13|K|14|1|15]]|9|$]]|$1|L|3|M|4|5|6|16|7|@]|8|@$J|17|K|18|1|19]]|9|$]]|$1|N|3|-4|4|5|6|1A|7|@]|8|@]|9|$]]]|O|$P|$4|Q|R|S|9|$T|U]]|V|$4|Q|R|S|9|$T|W]]]]

<blockquote>
 PHP application loses session information between requests. Since Stanford has multiple web servers, different requests may be directed to different servers, and session information is often lost as a result.
 
 The web infrastructure at Stanford consists of multiple web servers which do not share session data with each other. For this reason, sessions may be lost between requests. Using MySQL effectively counteracts this problem, as all session data is directed to and from the database server rather than the web cluster. Storing sessions in a database also has the effect of added privacy and security, as accessing the database requires authentication. We suggest that all web developers at Stanford with access to MySQL use this method for session handling.
</blockquote>

Referred from <a href="http://www.stanford.edu/dept/its/communications/webservices/wiki/index.php/How_to_use_MySQL-based_sessions" rel="nofollow noreferrer">http://www.stanford.edu/dept/its/communications/webservices/wiki/index.php/How_to_use_MySQL-based_sessions</a>

<a href="https://stackoverflow.com/questions/2316478/php-session-vs-mysql-speed">This</a> may help you.

blocks|key|277367|text|2)的答案是-+id取决于。让我解释一下:为了让会话处理程序正常工作，您确实应该实现某种类型的锁定和解锁机制。MySQL方便地提供了锁表和解锁表的功能。如果不在会话处理程序中实现表锁，那么就有可能在基于ajax的请求中出现竞争条件。相信我，你不会想要这些的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|277368|请阅读这篇详细介绍race+condition+in+custom+session+handler的文章：|offset|length|277369|好的，那么，如果你像你应该的那样向每个会话调用添加锁表和解锁表，那么你的自定义会话处理程序就会变得有点慢。|277370|可以做的一件事是使用堆表来存储会话，这样做的速度会更快。这意味着数据将只存储在RAM中，而不会写入磁盘。这将以极快的速度工作，但如果服务器宕机，所有会话数据都将丢失。|277371|如果您同意在服务器宕机时丢失会话，那么您应该改用memcache作为会话处理程序。Memcache已经有了所有必要的功能来使用一个php会话处理器，所有你需要做的就是安装memcache服务器，安装php的memcache扩展，然后添加一些类似这样的东西到你的php.ini|277372|[Session]
;+Handler+used+to+store/retrieve+data.
;+http://php.net/session.save-handler
;session.save_handler+=+files
session.save_handler+=+memcache
session.save_path="tcp://127.0.0.1:11215?persistent=1"|code-block|syntax|javascript|277373|这肯定比默认的基于文件的会话处理程序快得多|277374|使用MySQL作为会话处理程序的优点是，您可以编写自定义类来做其他事情，在将数据保存到会话时做额外的事情。例如，假设您将一个表示用户的对象保存到会话中。您可以使用自定义会话处理程序从该对象中提取用户名、用户it、头像，并将它们写入MySQL会话表中各自的专用列中，从而可以轻松地显示的在线|style|BOLD|277375|如果在会话处理程序中不需要额外的方法，那么就没有理由使用MySQL来存储会话数据|277376|entityMap|0|LINK|mutability|MUTABLE|url|http://thwartedefforts.org/2006/11/11/race-conditions-with-ajax-and-php-sessions/^0|0|9|14|0|0|0|0|0|0|0|3X|3|0|0^^$0|@$1|2|3|4|5|6|7|16|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|17|8|@]|9|@$D|18|E|19|1|1A]]|A|$]]|$1|F|3|G|5|6|7|1B|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1C|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1D|8|@]|9|@]|A|$]]|$1|L|3|M|5|N|7|1E|8|@]|9|@]|A|$O|P]]|$1|Q|3|R|5|6|7|1F|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1G|8|@$D|1H|E|1I|U|V]]|9|@]|A|$]]|$1|W|3|X|5|6|7|1J|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]]|Z|$10|$5|11|12|13|A|$14|15]]]]

The answer to 2) is - id depends. 
Let me explain: in order for the session handler to function properly you really should implement some type of lock and unlock mechanism. MySQL conveniently have the functions to lock table and unclock table. If you don't implement table locking in session handler then you risk having race conditions in ajax-based requests. Believe me, you don't want those.

Read this detailed article that explains <a href="http://thwartedefforts.org/2006/11/11/race-conditions-with-ajax-and-php-sessions/">race condition in custom session handler</a> : 

Ok then, if you add LOCK TABLE and UNLOCK TABLE to every session call like you should, then the your custom session handler will become a bit slower.

One thing you can do to make it much faster is to use HEAP table to store session. That means data will be stored in RAM only and never written to disk. This will work blindingly fast but if server goes down, all session data is lost.

If you OK with that possibility of session being lost when server goes down, then you should instead use memcache as session handler. Memcache already has all necessary functions to be used a php session handler, all you need to do it install memcache server, install php's memcache extension and then add something like this to you php.ini

<pre><code>[Session]
; Handler used to store/retrieve data.
; http://php.net/session.save-handler
;session.save_handler = files
session.save_handler = memcache
session.save_path="tcp://127.0.0.1:11215?persistent=1"
</code></pre>

This will definetely be much faster than default file based session handler

The advantages of using MySQL as session handler is that you can write custom class that does other things, extra things when data is saved to session. For example, let's say you save an object the represents the USER into session. You can have a custom session handler to extract username, userid, avatar from that OBJECT and write them to MySQL SESSION table into their own dedicated columns, making it possible to easily show Who's online

If you don't need extra methods in your session handler then there is no reason to use MySQL to store session data

blocks|key|277386|text|大多数语言标准库的会话实现只支持基本的键值关联，其中键由客户端提供(即会话ID)，值存储在服务器端(即会话存储)，然后与客户端的请求相关联。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|277387|除此之外的任何东西(特别是安全措施)也超出了键-值关联的基本会话机制，需要添加。特别是因为这些安全措施大多伴随着错误:如何确定某个会话的请求的真实性？按IP地址？通过用户代理标识？还是两者都有？或者根本没有会话身份验证？这始终是开发人员需要处理的安全性和可用性之间的权衡。|277388|但是，如果我需要实现一个会话处理程序，我不会仅仅追求纯粹的速度，而是--取决于需求--还包括可靠性。Memcache可能很快，但如果服务器崩溃，所有会话数据都会丢失。与之相反，数据库更可靠，但与memcache相比，它的速度可能会有所下降。但直到你自己测试和基准测试它，你才会知道。您甚至可以使用两个不同的会话处理程序来处理不同的会话可靠性级别(在memcache中是不可靠的，在MySQL/files中是可靠的)。|277389|但这完全取决于您的需求。|277390|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Most session implementations of languages’ standard libraries do only support the basic key-value association where the key is provided by the client (i.e. session ID) and the value is stored on the server side (i.e. session storage) and then associated to the client’s request.

Anything beyond that (especially security measures) are also beyond that essential session mechanism of a key-value association and needs be added. Especially because these security measures mostly come along with faults: How to determine the authenticity of a request of a certain session? By IP address? By user agent identification? Or both? Or no session authentication at all? This is always a trade-off between security and usability that the developer needs to deal with.

But if I would need to implement a session handler, I would not just look for pure speed but – depending on the requirements – also for reliability. Memcache might be fast but if the server crashed all session data is lost. In opposite to that, a database is more reliable but might have speed downsides opposed to memcache. But you won’t know until you test and benchmark it on your own. You could even use two different session handlers that handle different session reliability levels (unreliable in memcache and reliable in MySQL/files).

But it all depends on your requirements.

Right now I'm stuck between using PHP's native session management, or creating my own (MySQL-based) session system, and I have a few questions regarding both.

<ol>
<li>Other than session fixation and session hijacking, what other concerns are there with using PHP's native session handling code? Both of these have easy fixes, but yet I keep seeing people writing their own systems to handle sessions so I'm wondering why.</li>
<li>Would a MySQL-based session handler be faster than PHP's native sessions? Assuming a standard (Not 'memory') table.</li>
<li>Are there any major downsides to using <code>session_set_save_handler</code>? I can make it fit my standards for the most part (Other than naming). Plus I personally like the idea of using <code>$_SESSION['blah'] = 'blah'</code> vs <code>$session-&gt;assign('blah', 'blah')</code>, or something to that extent.</li>
<li>Are there any good php session resources out there that I should take a look at? The last time I worked with sessions was 10 years ago, so my knowledge is a little stagnant. Google and Stackoverflow searches yield a lot of basic, obviously poorly written tutorials and examples (Store username + md5(password) in a cookie then create a session!), so I'm hoping someone here has some legitimate, higher-brow resources.</li>
<li>Regardless of my choice, I will be forcing a cookie-only approach. Is this wrong in any way? The sites that this code will power have average users, in an average security environment. I remember this being a huge problem the last time I used sessions, but the idea of using in-url sessions makes me extremely nervous.</li>
</ol>

Creating custom PHP Session handler?

身份验证

数据库

服务器

MySQL

现在，我在使用PHP的本机会话管理和创建自己的(基于MySQL的)会话系统之间左右为难，我对这两者都有几个问题。除了会话固定和会话劫持之外，使用的本机会话处理代码还有什么其他的问题吗？这两个都很容易修复，但是我一直看到人们编写自己的系统来处理会话，所以我想知道为什么。基于MySQL的会话处理程序会比PHP的原生会话快吗...

问创建自定义PHP会话处理程序？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问创建自定义PHP会话处理程序？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问创建自定义PHP会话处理程序？
EN