Hey Michael,
Thanks for using the Feed Them Social Plugin! We are going to add this to the list of things to update! Thanks for detailed description!
slickremix on "[Plugin: Feed Them Social] Using this plugin on a secure site"
↧
↧
Duo Security on "[Plugin: Duo Two-Factor Authentication] https / preview bug with 2.0 (not in 1.8.1)"
This issue is caused by a failure in some SSL plugins to properly protect all authenticated pages with SSL. Errors in these plugins may leave your site(s) vulnerable to attacks by allowing authentication over non-SSL connections.
To protect your site credentials, Duo WordPress 2.x will log a user out if the base URL in the Duo cookie is different from the base URL of a page which requests authentication. Among other things, this prevents attackers from potentially stealing your credentials via a MITM attack (which is what SSL would be doing if it were actually protecting the necessary page(s)).
That is to say, when using SSL on your login page the base url picked up by the Duo WordPress cookie is https://example.com. Since https://example.com does NOT match http://example.com, you are logged out when a page begining with http://example.com requests unsecured authentication (preview pages, in this case).
Rolling back to 1.8.1 removes the issue because Duo WordPress 1.x does not perform this URL validation.
The quick (and most secure) resolution is to enable SSL site-wide by changing the base URL from HTTP to HTTPS in your general WordPress settings and removing any SSL plugin.
If you do not want site-wide SSL, the best resolution is to work with the author(s) of your SSL plugin to make sure that ALL authenticated pages are served over HTTPS. (We may also work with the authors of these types of plugins as we have the resources to do so.)
If you have any questions, comments, or support requests please direct them to support@duosecurity.com for further assistance.
Thanks!
↧
m00dawg on "[Plugin: Duo Two-Factor Authentication] https / preview bug with 2.0 (not in 1.8.1)"
Can't you just add a mode to turn that off (optionally with a big red warning)? The problem in my case is the front-end is crazy cached using a CDN which doesn't support CNAMEs with SSLs. Technically I suppose this is an issue with W3 Total Cache for not being able to specify HTTP and HTTPS URLs for the CDN.
That said, having Duo in place is surely better than the converse so I'd rather risk the HTTP vs HTTPS issue.
↧
Duo Security on "[Plugin: Duo Two-Factor Authentication] https / preview bug with 2.0 (not in 1.8.1)"
Thanks for the suggestion, m00dawg.
We had thought about adding an option like this, but weren't sure if it was something users wanted. Now that you've requested it, I'll file a feature request and we'll see where it goes.
CDN caching may be a factor. But I'm not inclined to think that it is here. I may not have been clear enough in my last post. The validation isn't simply HTTP vs HTTPS. Rather the validation checks that the base login URL (from http(s):// all the way up to the TLD) matches on any pages requesting authentication. Additionally, caching on your normal front-end pages shouldn't be problematic, as they do not require authentication checking with each page load the same way privileged pages (/wp-admin/, previews, etc.) do.
By the way, we're actively looking for beta testers to work with us on testing new versions of Duo WordPress. During beta installation/testing you'll be assisted live, over the phone, by a Duo engineer. If this sounds like something you'd like to help with, email support@duosecurity.com and let us know!
Thanks!
↧
m00dawg on "[Plugin: Duo Two-Factor Authentication] https / preview bug with 2.0 (not in 1.8.1)"
Ah but they actually can in a way. The problem is our site doesn't come up correctly using HTTPS to view any of the non-admin pages. So when we go to Preview, things end up being a bit of a mess.
I think you're right in that this is likely caused by a plugin (W3 Total Cache I'd bet). Trouble is, we can't just up and turn that off as it makes a huge difference in the amount of traffic that ends up hitting our website and, thus, to performance.
Where it gets really weird is with the top WordPress admin bar. That will get served on non HTTP. If I recall, the problem is noticed when you try to use that bar in that configuration.
Generally, I agree with you as far as HTTPS goes though we're not quite ready to do HTTPS-on-everything just yet even though it's an epically good idea.
↧
↧
Baden on "[Plugin: Collapse-O-Matic] not functioning in https?"
Very interesting!
Under HTTPS, your site is throwing the following errors:
Failed to load resource: net::ERR_INSECURE_RESPONSE https://173.254.40.239/resource/wp-content/plugins/jquery-collapse-o-matic/light_style.css?ver=1.5.7
Failed to load resource: net::ERR_INSECURE_RESPONSE https://173.254.40.239/resource/wp-includes/js/jquery/jquery.js?ver=1.10.2
Uncaught ReferenceError: jQuery is not defined icoi-resource.info/:27
Failed to load resource: net::ERR_INSECURE_RESPONSE https://173.254.40.239/resource/wp-includes/js/jquery/jquery-migrate.min.js?ver=1.2.1
Failed to load resource: net::ERR_INSECURE_RESPONSEThe problem is not just the plugin but the entire jQuery library.
After a bit of poking about, i think your problem might be due to:
https://icoi-resource.info/test1/
vs:
https://173.254.40.239/test1/
↧
steve955 on "[Plugin: Collapse-O-Matic] not functioning in https?"
Thank you very much for pointing me to the direction of the problem.
After calling my hosting support, I realized it's my Wordpress file structure issue.
It's all fixed now.
Thanks again for your great work!!
↧
BeTj on "[Plugin: Simple Instagram] Widget break HTTPS"
Using the the widget, break the integrity of using https on the website.
<li class="si_item">instagram.com/p/lnutpsGsuw/" target="_blank"><img src="http://distilleryimage7.s3.amazonaws.com/e8ed3794ad5c11e3be2f126b6b44507b_7.jpg">
↧
BeTj on "[Plugin: Simply Instagram] Break the integrity of HTTPS"
The widgets break the integrity of HTTPS. The output is "href="http://distilleryimage9.s3.amazonaws.com/*", any solution?
↧
↧
Baden on "[Plugin: Collapse-O-Matic] not functioning in https?"
Sweet! Glad you got it all sussed out. Don't forget to vote for pedro!
↧
hopetommola on "Force HTTPS or Relative URLs for Media in Posts"
I'm trying to identify the way to do this without yet another plugin. There has to be something in the loop which defines the protocol used for attached media. I just can't seem to find it ...
↧
msebald on "[Plugin: WP GPX Maps] WP-GPX-Maps not working on http sites - fix here so solved!"
Please fix this - in the new version it was still there so I had to repatch the file mentioned above for my HTTPS site.
It really does not hurt the HTTP sites when you change it that way. ;-)
Thank you! :-)
↧
jbenyair on "[Plugin: iThemes Security (formerly Better WP Security)] https backoffice"
Hi,
Sorry for my bad English
Since update ithemes security when i go to my backoffice there is in https and no http.
I check the settings and SSL is actived. I desactived it but no change my backoffice is always in https and no my front office
Any ideas?
Thks
↧
↧
jbenyair on "[Plugin: iThemes Security (formerly Better WP Security)] https backoffice"
Ok
After upgrading, the plugin add in my config.php this :
define( 'FORCE_SSL_LOGIN', true );
define( 'FORCE_SSL_ADMIN', true );
define( 'DISALLOW_FILE_EDIT', true );
ON/OFF in settings of backoffice not change anything
↧
Ipstenu (Mika Epstein) on "Force HTTPS or Relative URLs for Media in Posts"
You understand that the plugin handles all the code you're trying to write, right?
↧
hopetommola on "Force HTTPS or Relative URLs for Media in Posts"
Yes. But *every* aspect of the site, and server as a whole, is https already - even if you copy image address and paste into a new window, it forces ssl.
The *only* instance when content is not served via https is media in a post. To me, that seems like there must be a simple solution, related to the way the media is inserted.
Using a plugin to fix this feels redundant and will require additional maintenance. So, if there is a means to solve it otherwise, that makes more sense to me. No?
↧
Sarah on "Secure Submission (HTTPS) of Forms using Contact Form 7"
Hi mheitt – did you find a solution? Currently seeking the same fix. Thanks!
↧
↧
Ipstenu (Mika Epstein) on "Force HTTPS or Relative URLs for Media in Posts"
Yes and no.
Depends on your answer here: How did you set up WordPress to be HTTPS already?
↧
mheitt on "Secure Submission (HTTPS) of Forms using Contact Form 7"
Unfortunately, no. I'm really quite surprised that this is not a more frequent request.
michael
↧
dojwebmaster on "[Plugin: Autoptimize] Optimize HTML Code - Breaks SSL/HTTPS"
I can get the JS/CSS optimized with this plugin but when I enable Optimize HTML Code it breaks by SSL? And I get MIXED content warnings in Firebug for all my images?
What can I do? And thanks for the great plugin!!
↧
More Pages to Explore .....
