9
Quote:
aerograf wrote:
The ssl problem with mixed content, and decide now with the editors that have inserted links users excluding http: //. But not everyone supports ssl therefore looking for a solution through the above or /redirect.php?site=.
But not everything is working correctly.
Do ideas and solutions?
For internal links, where http links to your own site's content are embedded in your content, you can dump the database, replace all the occurrences, (i.e. change all
http://example.com to
https://example.com) and then reload it. There are also
tools to do that in-place in the database. It is a one shot task, and really should only take a few minutes.
For external links where you are essentially hot linking someone else's content, you either accept the warnings, or you implement some sort of proxy. That is expensive (you end up carrying bandwidth to fetch and send out resources from the other sites, up from 0% to 200% of the cost) and it is risky, you have to engineer in protection to keep your site from being used as a proxy by other sites (a situation that could consume an entire month's bandwidth for a low price hosting plan in a matter of minutes.)
If you had a robust cache strategy, you could cut down the resource requirements. We do something like that for oEmbed content in XOOPS 2.6 already. That concept could be adapted to handle http proxying for this situation. But, 2.6 has a much more scalable cache already. It also has a more modular text sanitizer which could help in implementing the details.
It isn't impossible, but it is not something everyone would want to put into place. At this point, it isn't feasible to dedicate that much additional effort to the 2.5 series.
If the basic support for self hosted content over SSL doesn't work, that is a bug and will be fixed. A comprehensive proxy solution for remote hosted content is an enhancement which will be deferred to the next generation of XOOPS.
