I am saving images in my db field like data:image/jpeg;base64,/9j/4AAQSkZJRgABAgAAAQABAAD/2wBDAAg......
When I display the images using
<cfimage action="writeToBrowser" source="#myField#"> on a normal page it works fine. When using in a cfdocument it doesn't work. I have seen some similar issues but haven't seen any of them work for me. I tried <img src="#myField#" /> but without any luck. Anyone get this working?
Thanks
When I've seen this before it was the CF 'browser' on that server not being able to connect to the /CFFileServlet/_cf_image/_cfimg-...PNG URL over loopback on that box. The exact cause and solution will depend upon how your web server, site config, SSL, firewall, routing, DNS are all set up.
Have you looked at error logs in CF Admin for the requests with the image errors? If you get no clues there then one way to help diagnose where it's failing is to wrap your <cfimage action="writeToBrowser" code in a <cfsavecontent> or <cfxml> tag to extract the src URL of the temp image written, and then see what result you get if you try and hit that same URL with a cfhttp call from the server - you should hit the same problem that cfdocument is getting, but you'll be able to dump out any errors to troubleshoot.
Depending upon the cause in your case, one of the following methods should work:
if the CF browser is unable to resolve its own hostname then add the site's domain to your server's local HOSTS file;
if a different vhost / IIS Site is being used when navigated to from the box itself than from the outside world, then make sure that the /CFFileServlet/ mappings are still visible on that site;
if cfdocument/cfhttp get SSL errors, ie if your site is using (or rewriting http to) https for these image requests, then make sure that your site's certs are trusted by your CF keystore;
Check your firewall config isn't blocking these internal requests.
Other lesser workarounds if you don't have access to solve above environment type issues:
a) rewrite the src URL from a relative URL to an absolute file:/// URL when used with cfdocument only.
b) if there is a localhost mapping to your site (on port 80 or otherwise) that is visible on your server, then you can try rewriting the src URL to use that instead of the FQDN.
c) instead of using writeToBrowser, write the cfimage output to a path of your choice that you can prove works with cfdocument/cfhttp and output your own img tag to serve the image from that path.
In my experience you'll see a lot of posts around about cfdocument and image paths and using localUrl=true - but where cfimage writeToBrowser is involved I have always found I needed
to use localUrl=false and rely on absolute URLs.
Just use isBase64="yes" attribute in your cfimage tag.Like this,
<cfimage isBase64= "yes" action = "writeToBrowser" source="#myField#" >
Related
in my rich body text fields, when an internal page is used for a link, the url that gets attached to the a tag is "https//example.com/example", ie it's missing the colon and the link doesnt work. I get the error "https's server ip address could not be found".
any idea why it is doing this? thanks
Check the site record under Sites -> Settings. The hostname field should NOT contain https - i.e. it should be example.com, not https://example.com.
in case anyone else has this issue, it seems having more than one site in wagtail caused this. I had the default localhost site still on there, even after switching to a new production site configuration. deleting the localhost site fixed this.
We have created a website which is served right now on Heroku. This website has a search bar in the navbar and I wanted to use Freefind search service for the backend. The search result I receive from it are all over the HTTP server and Heroku server will not load it.
I want them to work fine just as they work on localhost. What can I do?
The app is Django based and I tried to google custom search but it didn't work for me.
You can't load most HTTP content on HTTPS domains. Loading HTTP images is fine, but is still discouraged. This is called mixed content blocking, which is a browser's feature.
The only thing you can do is to find out if freefind's search service supports HTTPS. You can try changing the URL to https://search.freefind.com/... and see if it works. Or contact freefind and ask them if they support HTTPS. If they don't support HTTPS, you have to find a different company's search service.
I made a personal website (http://www.soyoungpark.online) using domain bought from GoDaddy and hosted on AWS s3. I set up everything and thought things were working until I put a simple link to my linkedin profile. When I check the network panel, I see that status code is 200 OK but for the response..there is nothing. The code itself doesn't seem to be problematic; it is simple a with href of the desired link. So I am guessing something could be wrong with my AWS s3 settings? Anyone with similar experience?
It's likely that these services include a header option called "X-Frame" that for security prevents them from being loaded within another site:
The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe> or <object> . Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites. Source: X-Frame-Options
This does look to be the case when attempting to view Linkedin per your example:
Refused to display 'https://www.linkedin.com/in/exampleuser' in a frame because it set 'X-Frame-Options' to 'sameorigin'.
That said, applying a target Attribute to each to open in a new tab or window should allow these outside services to be navigated to.
e.g:
<a href="https://www.linkedin.com/in/exampleuser" target="_blank">
I tried to view youtube videos on my app and it didn't work. I checked the console and got this error message
Mixed Content: The page at'https://hispanicheights.herokuapp.com/blog/youtube-video/'
was loaded over HTTPS,but requested an insecure script
'http://content.jwplatform.com/libraries/WQWJdvRx.js'.
This request has been blocked; the content must be served over HTTPS.
Is there a way around this or is this just the situation until I get a paid account with a domain?
This has nothing to do with Heroku, paid plans or not. It is simply that you are linking to an http resource inside a page that is served by https; since that potentially side steps the man-in-the-middle protection that https gives you, modern browsers forbid it.
The solution is to serve all your dependent scripts via https as well.
I'm trying to configure cubesviewer and try out the setup.
I've got the app installed running, along with cubes slicer app too.
However, when I visit the home page
http://127.0.0.1:8000/cubesviewer/
it fails popping up an error "Error occurred while accessing the data server"
Debugging with the browser console, shows a http status 403 error with the url http://localhost:8000/cubesviewer/view/list/
After some googling and reading, I figured I'll need to add rest frame auth settings. (as mentioned here.).
Now after running migrate and runserver, I get 401 error on that url.
Clearly I'm missing something with settings.py , Can somebody help me out.
I'm using the cubesviewer tag v0.10 from the github repo.
And find my settings here. http://dpaste.com/2G5VB5K
P.S: I've verified Cubes slicer works separately on its' own.
I have reproduced this. This is error may occur when you use different URL to access a website and to access related resources. For security reasons, browsers allow to access resources from exactly the same host as the page you are viewing.
Seems you are accessing the app via http://127.0.0.1:8000, but you have configured CubesViewer to tell clients to access the data backend via http://localhost:8000. While it's the same IP address, they are different strings.
Try accessing the app as http://localhost:8000.
If you deploy to a different server, you need to adjust settings. Here are the relevant configuration options, now with more comments:
# Base Cubes Server URL.
# Your Cubes Server needs to be running and listening on this URL, and it needs
# to be accessible to clients of the application.
CUBESVIEWER_CUBES_URL="http://localhost:5000"
# CubesViewer Store backend URL. It should point to this application.
# Note that this must match the URL that you use to access the application,
# otherwise you may hit security issues. If you access your server
# via http://localhost:8000, use the same here. Note that 127.0.0.1 and
# 'localhost' are different strings for this purpose. (If you wish to accept
# requests from different URLs, you may need to add CORS support).
CUBESVIEWER_BACKEND_URL="http://localhost:8000/cubesviewer"
Alternatively, you could change CUBESVIEWER_BACKEND_URL to "http://127.0.0.1:8000/cubesviewer" but I recommend you to use hostnames and not IP addresses for this.
Finally, I haven't yet tested with CORS support, but check this pull request if you wish to try that approach.