मुझे पूरी तरह से पता है कि अनुशंसित अभ्यास सिर्फ संपूर्ण साइट पर एसएसएल को मजबूर करना है।हालांकि, निश्चित रूप से अद्वितीय मामले हैं जहां HTTP और HTTPS के बीच चुनने और चुनने में सक्षम होना आसान हो सकता है।
मैं @Davavid Gardner के समान परिदृश्य में भाग रहा था। मेरी कंपनी हमारी साइट के हमारे स्टोर हिस्से को प्रबंधित करने के लिए एक थर्ड पार्टी विक्रेता का उपयोग करती है, और वह स्टोर सबडोमेन "https://store.mysite.com" पर रहता है। हमारे पास 15 साल की वीडियो सामग्री है, और एक एसएसएल में एक वीडियो एम्बेडेड होने पर हमारा वर्तमान वीडियो प्रबंधन विक्रेता टूट जाता है। (मुझे लगता है कि यह HTTP डोमेन से संसाधनों में खींच रहा है, लेकिन यह किसी अन्य दिन के लिए एक और समस्या है)
निश्चित रूप से, मैं एक एसएसएल खरीद सकता हूं और दो, तीसरे पक्ष के विक्रेताओं को डिबग करने की प्रक्रिया के माध्यम से जा सकता हूं किसी भी HTTP संसाधन लिंक को सही करने के लिए हमारे संपूर्ण डेटाबेस (या एक .htaccess फ़ाइल हैक, लेकिन मैं digress) पर एक खोज और प्रतिस्थापन, हेडर में एक संदेश प्राप्त करने में सक्षम होने के लिए "आपका स्वागत है" आपका नाम ", लेकिन ऐसा लगता है ओवरकिल की तरह
यहां एक साधारण जावास्क्रिप्ट समाधान है जो मैं आया हूं, जो कि पहले से सेट की गई सुरक्षित कुकीज़ के आधार पर साइट-व्यापी, असुरक्षित कुकी सेट करता है।
पहला, I grabbed some javascript cookie functions। आगे बढ़ो और अपनी साइट के सुरक्षित भाग में इस कोड डाल:
function readCookie(name) {
var nameEQ = name + "=";
var ca = document.cookie.split(';');
for(var i=0;i < ca.length;i++) {
var c = ca[i];
while (c.charAt(0)===' ') {
c = c.substring(1,c.length);
}
if (c.indexOf(nameEQ) === 0) {
return c.substring(nameEQ.length,c.length);
}
}
return null;
}
function setCookie(cname, cvalue, exdays) {
var d = new Date();
d.setTime(d.getTime() + (exdays*24*60*60*1000));
var expires = "expires="+d.toUTCString();
/* Note, the W3 documents where I got this code didn't include the
option to set the domain. I added this and it allows the cookie
to be shared across sub-domains. Be sure not to add "www" */
document.cookie = cname + "=" + cvalue + "; " + expires + "; domain=.yourdomain.com";
}
/*Now we check our cookies on our secure server to find out if the user is
logged in or not. In my case, the First Name is stored as a cookie. */
var firstNameCookie = readCookie("the-secure-cookie-name");
//
if(!firstNameCookie){
/* If the cookie doesn't exist, then the person isn't logged in. Add
conditional logic here if you'd like (such as deleting any current
logged in cookies from the HTTP portion of the site) */
}
else {
/* otherwise, we have a successful login. By grabbing the cookie via
this javascript resting on the secure server, we haven't compromised our
security. However, if we set a cookie with javascript right now, it
won't be a secure cookie by default and we'll have access to it with
HTTP on the subdomain */
setCookie("HTTPfirstName", firstNameCookie, 1.5);
}
*/The clients first name is now accessible across subdomains in the cookie
entitled "HTTPfirstName" */
इस उदाहरण में, केवल एक ही चीज़ हम अपने HTTP सर्वर के लिए खत्म हो गया है लीक ग्राहक का पहला नाम है। हालांकि, अगर आप और भी सुरक्षा चाहते हैं, तो आप अपनी सर्वर सेटिंग्स को केवल कुछ अनुरोधों (यानी "फर्स्टनामक्यूकी) को HTTP अनुरोध द्वारा एक्सेस करने की अनुमति दे सकते हैं, और यह सुरक्षा की एक अतिरिक्त परत जोड़ता है। You can learn how to do that here
निश्चित रूप से, यह सबसे आदर्श समाधान नहीं है। भविष्य में, मैं एसएसएल साइट-वाईड को लागू करने की योजना बना रहा हूं, लेकिन इस दौरान इसे बदलने के लिए एक सरल जावास्क्रिप्ट फ़ंक्शन होना निश्चित रूप से अच्छा है।
शायद क्योंकि सुरक्षित कुकीज़ और HTTP डॉन अच्छी तरह से एक साथ खेलना नहीं है? मैंने बिल्कुल इसे लागू करने की कोशिश की, लेकिन जब उपयोगकर्ता HTTPS छोड़ देता है (जहां तक मैं बता सकता हूं) सुरक्षित कुकीज मिटा दी जाती हैं। http://stackoverflow.com/questions/16734090/http- पेज-रीमूविंग-माय-सुरक्षित-कुकीज –