This seems possible, but I'm missing something. I'm using plone.app.theming (diazo). I'm trying to pull in pages from a cold fusion site. I can get the first page to load using but the page then has urls that refer to more data pages. The urls are formatted like this "./undergraduates_classes_info.cfm?crse=001A§num=A" (which Plone is more than happy to parse) I've tried a variety of permutations to this and I can't seem to get it to work.
<xsl:param name="ExtUrl" select="'http://exeternalsite'" />
<xsl:template match="a/#href[contains(.,'/undergraduates')]">
<xsl:attribute name="href">
<xsl:value-of select="concat($ExtUrl, .)" />
</xsl:attribute>
</xsl:template>
I also need to pass the url to the command so that i can get the actual data back.
Any help is appreciate -- and maybe I'm approaching this incorrectly?
It's a very bad idea to depend on a remote service before you can finish processing the request. Imagine that site goes down or is slow? Now you're waiting on it to finish or timeout before you serve your page.
A better solution is to use javascript to pull in the contents of the page.
It could look something like this:
$(document).ready(function(){
$('#containerofcontent').load('http://remoteurl #contentselector');
});
Assuming your site is on a different domain, you'll also need to set some special headers on the remote site in order for browsers to allow the ajax request:
Access-Control-Allow-Origin: http://plonesiteurl
That's pretty easy to override headers with any web server though.
You can include content from an external site by specifying the href attribute as documented here: http://docs.diazo.org/en/latest/advanced.html#including-external-content
You will need to enable the "Read network" option in plone.app.theming to allow inclusion of external urls, see: http://pypi.python.org/pypi/plone.app.theming#usage
As others have pointed out, this does have a performance impact, but if you are caching the resulting pages that might be ok. You can avoid that performance cost by caching the fragment and using the SSI or ESI method options documented on the diazo site, but you will need to setup Nginx to run the filter.xsl stylesheet or a diazo proxy.
Unless I am misunderstanding your question (always possible), I think you are misunderstanding p.a.theming. p.a.theming can include theme assets (e.g. templates, images) from a remote site, but it is not intended for nor really capable of proxying in content from a remote site.
Related
I am getting the path /#! requested regularly on my blog and i was wondering why this was (as it doesn't match to any URL/resource on my blog). The user agent says its always IE7 browsers which request this but from multiple different IP Addresses. I'm trying to work out if I can ignore this or if I need to do something about it.
I specifically want to know the following:
Is it some kind of special URL for certain web browsers/web servers?
Is it connected to a specific exploit?
Can I just ignore it?
If its relevant the site is hosted in windows azure and running on MVC4.
It's a hash-bang URL. They're used by some AJAX web applications, like Facebook and Twitter. Google has some special treatment for them, to make normally uncrawlable AJAX sites crawlable.
However, if your site is not running an app that uses them, you shouldn't be seeing them. And you definitely shouldn't be seeing them on the server side, since the whole point is that everything following a # in a URL is a fragment identifier, and should be stripped off by the user agent before requesting the URL from the server.
Edit: If I had to guess what's requesting such URLs, I'd say it might be some buggy bot. The fact that it's apparently pretending to be IE suggests that it might not be up to anything good; maybe it's a spambot of some sort. Anyway, the requests as such are most likely harmless, and you can ignore them. If it makes you feel better, you could always set up a rewrite rule to explicitly reject them, something like:
RewriteRule \x23 - [F]
This should reject any requests for URLs containing the # character with a 403 Forbidden error.
Well, # is a valid anchor that just means "the page". You can also make a '!' anchor, e.g.
<!-- some html here -->
Click me!
<!-- lots more html -->
<div id="!">
Wooaaaah!
</div>
So my guess is that you can safely ignore it... but that's just a guess ;)
this is a broader question than I would probably ask of the CartThrob folks, which is why I'm posting it here. What would the community recommend as far as SSL is concerned with CartThrob? The store functions are limited to a couple of key template groups. So my thinking was perhaps the best way to handle it would be htaccess on the basis of the presence of those URL segments. I would like to return the user to a non-SSL connection when they are not in the store area. So a trigger might be the first segment being "basket" or "account" for example. Or what about an in-template redirect to the secure URL? Very interested to hear the community's suggestions on how best to handle SSL within a given area of an EE site. I'm interested in whatever makes the most sense to implement, while also ensuring that, for example, all assets - even those loaded with path variables - are loaded via SSL. Thanks all!
I've always used CartThrob's https_redirect tag (docs) on my checkout screens, which will rewrite your {path}, {permalink} (etc)-created URLs to use https, as well as redirect you to the https:// version of your page if necessary.
That, combined with using the protocol-agnostic style of calling scripts and stylesheets should get you most of the way in getting your secure icon in the browser.
(Example:)
<script src="//ajax.googleapis.com/ajax/libs/jqueryui/1.9.1/jquery-ui.min.js"></script>
I'm having a problem with a clients magento site that has https enabled on the secure pages,
The website it built heavily around static block content and on the https pages images are pulled from static blocks (over 400 of them) using the media insert in the static block {{media url="media/bla/bla/bob.png"}} these images are comign through as http://site.com/media/bla/bla/bob.png
its not realistic, and it wouldn't make any sense to go through and change all these links to direct links.
Any ideas?
Cheers
Roly!
You are suppose to use the {{store url=""}} or the {{secure_base_url}}media/ in ur blocks
if ur not certain that ur page will be on HTTPS or HTTP the use first one if you know for sure that the request will be HTTPs use second one. (NOTE. Second is a system config path not the actual value that u'll put in the CMS block).
Hope it helps.
Whereas media files are not subject to a fallback, and with the awareness that if the directory level for Magento changes w/r/t the webroot (e.g. http://site.com/ vs. http://site.com/magento/) you can lead with the double-slash network location:
<img src="//media/bla/bob.png" />
Therefore, a search and replace against using the current data in cms_block.content is indicated.
I'll reiterate that this is not appropriate for skin assets due to the fallback.
I've added a SSL certificate to an existing site, and now in IE I get a mixed content warning. Problem is, I don't know what's the non-secure content IE is warning me about. It's a simple html page, with a few Flash, a few images, a loaded CSS and JS.
How can I find out what's the non-secured content..?
Edit:
I found the culprit: it's the JS AC_RunActiveContent.js used to display Flash movie. So anyone has an idea on how to prevent SSL mixed content when using AC_RunActiveContent.js.?
This means that something is requesting content using the http protocol specifically, or you have an absolute path to an image or other content that begins with http instead of https.
A few tips: Use relative paths everywhere you can. If you must use an absolute path, and it's to a server you own, use https. If you're loading stuff from off your site, you're probably stuck with the mixed-content warning.
This also goes for your scripts, check out the JS, and the CSS template and make sure they're not the guilty parties - if they are change them to use relative paths, or to request items via https instead of http (assuming you're positive that the server they're referencing supports https, if it doesn't you're stuck).
There are a few other details, this might be helpful.
Ok, so here is the solution for my particular problem. It was the codebase value in my code that needed to be https as well (I didn't think it would trigger the warning, as my Flash were displaying correctly, oh well)...
AC_FL_RunContent( 'codebase','https://download.macromedia.com/pub/shoc...
Link to Adobe info on this: Security Information error in Internet Explorer
I use the Firefox console -- it reports the http resources it blocks from fetching on a mixed content page.
Search your source for http: only. Another great tool to help you out is Fiddler with which you can see what's getting downloaded upon requesting your page.
I have a WSS 3.0 system using SSL where every page is supposed to be served as https. Almost all pages do come out as https, but in certain cases I click on a link and that brings up an http version of a page (which does not load). In those cases I have to put the 's' in by hand to get the page to load. Places where this happens are:
/_layouts/newgrp.aspx : when I try to create a new group, it takes me to http://server/_layouts/newgroup.aspx, although it should be https. The page does not load at http. It does load if I change the url by hand.
/_layouts/edtgrp.aspx : same thing as newgrp.aspx
if I go into a document library and view version history for a file, the URLs to the individual versions of that file are http. Interestingly, the browser status bar also indicates http when I hover over them (so it seems that SharePoint gets confused when it generates the links, rather than when I click on them)
To fix this, I have tried adding some javascript to the DOM that searches for instances of http and replaces them with https. This works in some cases, but there are some places where javascript can't reach, for example when SharePoint provides the target URL in response to a POST request, which I think is the case with newgrp/edtgrp.aspx.
I have also tried adding ISAPI filters to redirect pages from http to https. This seems to cause redirect loops, and in any case I'm not sure if such filters would preserve querystring or POST information.
Has anyone seen this problem?
Update: We have switched to ISA from Squid, and the problem continues in the version history, but not on new group or edit group. We have not seen any improvement yet from changing AAM settings.
Places where this is happening in ISA:
"Version History" under item in list or document library
"Manage Permissions" under item in list or document library
"Alert Me" under item in list or document library
"Add Users" menuitem in "People and Groups" page
"Group Settings" menuitem in "People and Groups" page
"Edit Group Quick Launch" menuitem in "People and Groups" page
"Set Up Groups" menuitem in "People and Groups" page
"List Settings" menuitem in "People and Groups" page
Not sure if this is it, but have you checked your alternate access mappings to make sure they say https instead of http?
I would echo the suggestion to check your Alternate Access Mappings. Is the SSL being done on the SharePoint Front Ends, or is it being done via a piece of dedicated SSL hardware?
Use an HTTP Module to modify SharePoint's output so that links are always changed to https. Such a module can plug into IIS and modify the HTML of anything rendered. I've used this technique to make SharePoint XHTML compliant and it works well.
Even better, almost all of the work has already been done for you. The UrlRewritingNet module is open source and available for free download. It should work fine for your SharePoint site. This tool has great documentation and uses regular expressions to match which URLs to alter. It should be pretty easy to write one for your case, e.g. ^http://. There's also many more advanced options you can take advantage of if necessary.
If you'd prefer to write your own then there is a good article called Rewrite.NET -- A URL Rewriting Engine for .NET on the 15 Seconds site.
Finally, if you're using IIS 7 you could try its URL Rewrite Module. I've never used this myself and don't know if it works with SharePoint, but it's the most UI-driven solution available.
Add a redirect in IIS from http to https. Every time you access that page it will redirect you to your https page instead.
I would also suggest placing WSS on another server to see if you have the same problems. If you don't, you might need to rebuild/migrate your stuff over.
Alex answered this question with an approach that I think will generally work. Here is how I fixed this specifically.
It looks like when a SharePoint aspx page is loaded, it populates a javascript structure of type ContextInfo (defined in init.js), which is instantiated in the variable ctx. That structure has a member called httpRoot, which is later used in core.js to build menuitems in various dropdown.
This ctx.httpRoot is for some reason populated in javascript in the aspx files created by SharePoint with a line like this:
ctx.HttpRoot = "http:\u002f\u002fsubdomain.domain.com";
Yes, it has Unicode slashes and it has http instead of https. I have no idea why. But, fixing this line of javascript seems to fix the problem.
I changed the line by adding a URL translation rule in ISA that converts http:\u002f\u002f\ to https:\u002f\u002f\ . I suspect that an HTTP module that makes the same replacement would also work. Or possibly some well placed javascript that reassigns the variable at some point.
I still believe this is not ideal and there must be a more appropriate way to fix these links.