I set up the following mapping in the admin:
Virtual: /css
Resource: /resource/css/v1/
Now, how do I resolve this mapping so I can link to my css files? How can I resolve the /css mapping so that I can get <link href="/resource/css/v1/mycss.css">?
I went through the system function list but I couldn't find the right function. Thanks.
The mappings set in Railo admin are not for HTTP requests, they are so the CFML server can locate source code files. They have no bearing on URLs for requests.
CSS requests do not hit the CFML server, they are handled by the web server, so you need to set up a virtual directory on the web server, not a mapping in Railo admin.
Related
I would like to know if it is possible to allow localhost to make changes to a specific site by setting it in the csp header in the settings.py file of the Django project. For my part, I am trying to load my Django site in an iframe present on a page at the following address http://localhost:3000/searchEngine. So I inserted this in my settings.py file:
CSP_FRAME_ANCESTORS = ("'self'", 'localhost:*')
This is taken into account, but still does not allow localhost to load the site in the iframe and I get the following error, when I try to load this site in the iframe:
Refused to frame 'https://gkwhelps.herokuapp.com/' because an ancestor violates the following Content Security Policy directive: "frame-ancestors 'self' localhost:*".
I don't know not why yet I did not make syntax errors. So I wonder if django-csp takes localhost into account. I would like to allow my site to load in an iframe from any port in my localhost.
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#" >
Setting up production lucee box, having issues locating ajax library in lucee server. My browser unable to find ajax library showing 404 error.
I am not sure this is because of firewall or lucee server configuration issue.
My development and staging working fine only having issue in production server.
Request URL: https://example.com/mapping-tag/lucee/core/ajax/JSLoader.cfc?method=get&lib=LuceeAjax
Request Method: GET
Status Code: 404
Remote Address: 201.10.26.29:443
Referrer Policy: no-referrer-when-downgrade
Please advise..
With an Adobe CF server, the JS files related to cfajaxproxy are in the /CFIDE/scripts/ folder. The /CFIDE/ folder is removed from public access when the server is locked down. To allow access to the JS files for the UI and ajax tags, you can specify an alias in CF Admin for that folder.
For example, /cfjs would map to /CFIDE/scripts in CF Amin, so CF will generate that path for cfajaxproxy use. You'd have to create this folder alias in IIS or whatever web server you're using.
If on Lucee, the folder /lucee/core/ is blocked when locked down, there should be a similar solution for that engine.
I have an ember app that I have been building. It has several routes including index (/) and authorization (/authorization). My trouble is that when the application is hosted on hostgator, loading the url myapp.com/authorization results in a 404. This makes sense since there is nothing at that actual url. I need hostgator to redirect all non-file-specific urls to my index.html file.
An example in psuedo code:
if url has extension (.jpg, .pdf, etc)
serve requested url
else
serve index.html but retain url in the address bar
I've done this sort of thing with local instances of node when using AngularJs with ui-router, but this is my first time using History-API based routing served from HostGator.
Any suggestions on where to start to set this up?
Not much of an answer but you can use locationType: 'hash' in environment.js as your configuration.
With locationType set to 'auto', refreshing on application hosted on Hostgator will produce a 404. I have encountered this before and not found any solution. So I switched to 'hash'.
If you find any solution, please tell me. Thanks!
First of all, google or SO search didn't help me: lots of tips regarding django's staticfiles, which I believe are not relevant here.
I have inherited a project consisting of:
Django backend in form of API returning JSON responses only;
standard Swampdragon deployment pushing realtime updates to frontend; very little configuration has been done here;
Frontend webapp built on Backbone and marionette.js, compiled and minified by Grunt.
My problem is: the frontend needs to know addresses for swampdragon and django servers; right now those values are hardcoded, so there is for example a Backbone model with lines like:
url: function() {
return App.BACKEND_URL+'settings/map';
}
Why hardcoded: backend can be served on any port or have a subdomain to itself; frontend is static and normally would be simply thrown into /var/www (for Apache) or would use some very simple nginx config. Both will be served from the same place, but there is no guarantee the port numbers or subdomains would match.
Idea number 1: try to guess what BACKEND_URL is from javascript, by taking window.location.host and appending standard port. That's hackish and error prone.
Idea number 2: move frontend to Django and make it ask for swampdragon credentials (they would be sent in the context of home view). Problem with that is, the frontend files are compiled by grunt. So where Django would kindly expect something like:
<script src="{% static 'scripts/vendor/modernizr.js' %}"></script>
I actually have
<script src="scripts/vendor/a8bcb0b6.modernizr.js"></script>
Where 'a8bcb0b6' is grunt's hash/version number and will be regenerated during next minification/build. Do I need to add additional logic to get rid of such stuff and copy grunt's output directory to django's static and template dirs?
Or is there another way to make this work, the right one, I am missing?
Your architecture is already clean, no need to make Django know about grunt or serve static files, and no need to use JS hacks to guess port numbers
Reverse Proxy
Use a reverse proxy like nginx or any other web server you like as a front end to both the static files and the REST API.
In computer networks, a reverse proxy is a type of proxy server that
retrieves resources on behalf of a client from one or more servers.
These resources are then returned to the client as though they
originated from the proxy server itself. (Wikipedia)
I will outline the important aspects without going into too much detail:
URL for the REST API
We make configs so that nginx will forward the API requests to Django
location /api {
proxy_pass http://127.0.0.1:8000; # assumes Django listens here
proxy_set_header Host $http_host; # preserve host info
}
So the above assumes your Django REST is mapped to /api and runs on port 8000 (e.g. you can run gunicorn on that port, or any other server you like)
http://nginx.org/en/docs/http/ngx_http_proxy_module.html
URL for our front end app
Next nginx will serve the static files that come out of grunt, by simply pointing it to the static folder
location / { alias /app/static/; }
The above assumes your static resources are in /app/static/ folder (like index.html, your CSS, JS etc). So this is primarily to load your BackboneJS app.
Django static files
Next step is not required, but if you have static files that you use with the Django app (static files that are generated with ./manage.py collectstatic, e.g. the django admin or the UI of Django REST Framework etc), simply map according to your Django settings.py STATIC_URL and STATIC_ROOT
location /static { alias /app/django_static_root/; }
/static and django_static_root being the STATIC_URL and STATIC_ROOT respectively
To sum up
So e.g. when you hit example.com/, nginx simply serves up the static files, then when a JS script makes REST call to /api, it gets trapped in the /api nginx location and gets forwarded to Django
End result is, example.com/ and example.com/api both hit the same front end web server, which proxies them to the right places
So there you have it, reserve proxying solves your ports and subdomain issues (and many others, like slow static files from Django and same-origin policies in web browsers and firewalls not liking anything besides default HTTP and HTTPS ports)