发布到https表单并不总是有效

本文介绍了发布到https表单并不总是有效的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述 29岁程序员，3月因学历无情被辞！ 在我的网站上，我有一个简单的登录表单。该页面通过HTTP提供，但表单的POST URL为HTTPS。 正常方法是用户填写用户名/密码，表单已提交（至完全限定的HTTPS URL，在同一站点上），然后POST处理将303重定向到用户的主页。但有时这种情况不会发生。 这个周期（这是100％可重复的）是： 访问登录表单，填写详细信息并提交 在服务器上调用登录脚本，验证数据然后，如果一切正常，则执行303重定向到用户主页。 然后单击注销然后单击登录，此时我将返回登录表单 然后我再次填写我的详细信息，点击提交。 但是，这次登录逻辑没有执行（在步骤2登录登录的调试代码没有得到叫，但我仍然被重定向到用户主页。但是因为我没有成功登录，所以我被踢到头版... 那么为什么不呢？ POST总是调用登录表单？我不认为303正在被缓存（根据规范，它不应该是......） 查看服务器中的HTTPS日志， login.phpo是第一次被调用，但不是第二次.... 编辑： 好的，我们已经解决了这个问题。对于那些感兴趣的人： 该站点在负载均衡器后面的2个Web服务器上运行。用户会话是粘性的 - 也就是说，一旦用户在一个Web服务器上浏览，LB就会将它们附加到该服务器上。这是通过cookie完成的。但是一旦我们切换到HTTPS，LB就无法读取cookie，因为连接在浏览器和Web服务器之间是加密的。所以它在服务器之间交替。我们有代码在Web服务器之间传播登录身份验证，但这种情况发生得不够快。所以发生的事情是： 用户浏览器到服务器A，得到一个cookie，说'让我保持A'，填写他们的登录凭据并点击提交 LB无法解密HTTPS流量（以及cookie），将50％的时间发送给B B验证登录并设置要在会话中进行身份验证的用户，然后将用户重定向到非https主页 因为主页是非https，LB会读取cookie并发送他们到A，它不知道认证，因为它没有从B传播得足够快... 解决方案是允许LB解密HTTPS流量，从而确保用户确实留在一个Web服务器上，无论HTTP / HTTPS转换如何。解决方案 我不认为303正在被缓存（根据规范，它不应该是......） 不，浏览器不会缓存303，但某些其他级别可能会缓存它或序列中的其他页面。此外，假设您使用cookie来存储登录状态，您需要确保设置'path'和'domain'以便设置和删除相同的cookie，而不是为站点的不同部分设置多个阴影副本。 需要更多诊断代码。 该页面通过HTTP提供，但表单的POST URL是HTTPS。 不要这样做。用户无法在不查看源手动（并检查引用的每个脚本）的情况下告诉操作URL将是HTTPS，这不会发生。 因此，中间人攻击者可以通过简单地使用登录表单更改初始HTTP页面来获取身份验证详细信息。这使得对POST接收器的任何保护完全没有用。 登录过程的每个阶段，包括任何包含登录表单的页面，都必须在HTTPS上才能获得任何从中受益。 On my site I have a simple login form. The page is served via HTTP, but the form's POST URL is HTTPS.The normal method is that the user fills in their username/password, the form is submitted (to the fully qualified HTTPS URL, on the same site), and then the POST processing does a 303 redirect to the users' homepage. But sometimes this doesn't happen.The cycle (and this is 100% repeatable) is this:Visit login form, fill in details and submitOn the server the login script gets called, validates the data and then , if all is well, does a 303 redirect to the users home page.I then click logout and then click login, at which point I'm taken back to the login formI then fill in my details again, hit submit.This time, however, the login logic doesn't execute (the debug code that logged the login at step 2 doesn't get called), and yet I'm still redirected to the users homepage. But because I've not been logged in successfully, I get kicked out to the front page...So why isn't the POST always calling the login form? I don't think the 303 is being cached (and it shouldn't be, according to the spec)...Looking at the HTTPS logs in the server, login.phpo is being called the first time, but not the second....Edit:OK, we've solved the problem. For those that are interested:The site is run on 2 webservers behind a load balancer. user sessions are 'sticky' - that is to say once a user is browsing on one web server the LB will keep them 'attached' to that server. This is done via a cookie. But once we switch to HTTPS the LB can't read the cookie, as the connection is encrypted between the browser and web server. So it was alternating between servers. WWe have code to propagate login authentications between webservers, but this wasn't happening fast enough. So what was happening was:User browsers to server A, gets a cookie saying 'keep me on A', fills in their login credentials and hits submitThe LB, being unable to decipher the HTTPS traffic (and thus the cookie), sends them 50% of the time to BB validates the login and sets the user to be authenticated in the session, before redirecting the user to the non https homepageBecause the homepage is non https, the LB reads the cookie and sends them to A, which knows nothing of the authentication since it wasn't propagating fast enough from B...The solution was to allow the LB to decrypt HTTPS traffic, thus ensuring that users really do stay on one web server, regardless of HTTP/HTTPS transitions. 解决方案 I dont think the 303 is being cached (and it shouldnt be, according to the spec)...No, a 303 won't be cached by the browser, but some other level might be caching it or other pages in the sequence. Also, assuming you are using cookies to store login state, you need to ensure that you're setting ‘path’ and ‘domain’ so that the same cookie is being set and deleted, instead of multiple shadowed copies for different parts of the site.More code needed to diagnose. The page is served via HTTP, but the form's POST URL is HTTPS.Don't do that. The user has no way of telling that the ‘action’ URL is going to be HTTPS without looking at the source manually (and checking every script referenced), which isn't going to happen.So it's possible for a man-in-the-middle attacker to grab authentication details by simply altering the initial HTTP page with the login form. This makes any protection on the POST receiver entirely moot.Every stage of the login process, including any page containing a login form, must be on HTTPS for you to get any benefit from it. 这篇关于发布到https表单并不总是有效的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 上岸，阿里云！