My site requires the user to be logged in via onRequestStart() in Application.cfc.
Then there is the registration folder, which has an Application.cfc that extends ApplicationProxy.cfc which extends the root Application.cfc.
This way the registration folder doesn't require the user to be logged in.
My problem is that the path on my dev server is different than the path on the production server.
So now my code is out of sync between dev and production because dev extends "clientname.components.ApplicationProxy" while production extends only "components.ApplicationProxy".
/Application.cfc
/components/ApplicationProxy.cfc extends Application
/Registration/Application.cfc extends ApplicationProxy
It'd be best to use CF w/ Apache in a Multi-instance setup to mirror your dev folder structure just like your production folder structure.
I'm pretty sure you just be able to create a mapping in the CF admin. For example create a mapping called appextend, on dev it can point to clientname.components and on live just components. Then you can extend appextend.components.
Also check out this post: http://corfield.org/blog/index.cfm/do/blog.entry/entry/Extending_Your_Root_Applicationcfc
Related
Good morning. I have a dedicated ubuntu server behind my company's firewall. It is using Django, Gunicorn, and Nginx to serve an Intranet application to employees. The original app responds to the URL [server_name]/[original_application_name]. I want to serve additional apps from this server. I have followed this tutorial as I did when setting up the original app.
I can run Gunicorn and serve the app, I have created a second systemd service file that appears steady (copied from the original app with paths changed - service runs), same for a new 'sites-available' file in Nginx (copied from original and modified), new .sock file exists, binding appears successful. However, I have yet to hit on the right configuration combination between settings.py [allowed_hosts], [new_app].service, and nginx etc.
The original app is running and when I try a URL related to the new app it gives an error saying it cannot find the request in the url.py of the original app. The new app would be used by the IT dept. Ideally, the new URL would be something like: it.[server_name]/[new_application_name].
I have looked through other cases with this problem but most use Apache or are on a public hosting site. I have seen this but it requires a "socket file". My original app is not using a socket file. I was hoping to do this without interfering with the original app. Is a "socket file" required? How can I configure this to serve both apps? Never having done this, what will the new URL be? The URL for the admin site in both apps is 'admin/', how can I accommodate this? Thanks!
I combined into one file as you suggested and I am almost there! I have original site responding at [server_name]/inventory and new site responding at [server_name]/assets. Great! My only problem is the admin page. In both apps the admin site is called admin! So, [server_name]/admin brings up the original site. How can I get to the new admin page?
I am planning to convert a django project to Progressive Web App. I am not being able to figure out where to put the service_worker.js and manifest.json files in my django project. I've tried the following:
myproject/
|__app1
|__app2
|__manage.py
|__manifest.json
|__service_worker.js
and then tried to register the service worker from html file using relative path ../../../service_worker.js. That didn't work. It showed this error: "A bad HTTP response code (404) was received when fetching the script."
Another approach I tried is to put the service_worker.js and manifest.json in the static folders:
myproject/
|__app1/
|__static/
|__app1/
|__service_worker.js
|__manifest.json
|__app2
|__manage.py
and access those using {% static 'app1/service_worker.js' %}. The problem with this approach is that the scope of the registered service_worker.js becomes limited to that static folder. I've seen in one stackoverflow answer that I can explicitly set the scope of the service worker as {scope: '/'}. But, I think there might be a better approach which I am missing. Please let me know if anyone has a solution to this.
Looks like you want to have a common SW for all your app(1, 2). You can have both SW and manifest.json at the project root, link the manifest to your project's home page. If you want to cache the whole path, setting scope is not a bad idea, as the same has been officially documented here.
Look for "Registering your worker" part in the linked page.
Service Worker needs to be served from the same path it will handle so if you put after static,.it will handle only static/ so to put under '/' you have to create a view that returns the Service worker js.
def sw(request):
return HttpResponse(settings.SERVICE_WORKER)
Note: you can use django template to generate the final js
For Manifest, it is a usual static file.
I am using the ember quick-start tutorial app. Everything works great locally, but when deployed to a test environment the app is 404ing on loading all resources.
I am deployed to a subfolder out somewhere and apparently ember is trying to find it against the root domain, instead of subfolder
Example:
http://example.com/embertest/index.html
The assets folder is obviously under http://example.com/embertest/assets/, but on load it's trying to grab it from http://example.com/assets/ which doesn't exist
How can I have ember use relative paths in this case?
Update 1
After some googling I tried editing the environment.js ENV.baseURL attribute
In the if(environment === 'production') block I added ENV.baseURL = '/website/dist/';, obviously I am building with ember build --env production
I am getting same 404s when going directly to a route but now also getting an error on index.html, Uncaught UnrecognizedURLError: /index.html
I tried every combination of '/website/dist/', 'website/dist/', '/website/dist' as well
Update 2
I have now also tried manually editing the <base href="/website/dist/"> in my index.html after a prod build. Same errors as from update 1
You need to understand that you can't just put an ember application to a normal webserver folder. Ember uses the history API to change the URL when you do a route change but it can't control what your web server deploys when its directly fetched.
So you have your ember index.html on http://example.com/app/index.html your web server usually will only deploy this file when you open http://example.com/app/ or http://example.com/app/index.html. But for a route foo your url is http://example.com/app/foo and your web server is looking for a directly foo that does not exist. So you have to configure your web server so its always responding with your index.html if your not requesting another existing resource (like an image, js or css file)!
How to do this depends completely on your webserver.
You must also notice that you should enter your assets in a full root relative path and specify rootURL so your router knows which part of the URL is your path and where your routing begins.
You should not use baseURL because its an upcoming deprecation!
You really should read this really new blog post!
Use ENV.locationType = 'hash' to prevent the usage of the history API is still always an option, but definitly an ugly one.
Okay so I solved this by changing ENV.locationType = 'hash' in environment.js
Would still love an explanation of what's going on as this feels a little bit hacky...
I've been developing a site with sensitive (i.e. proprietary) code on my local machine, testing it using apache2, and I'm finally going to be getting it setup with a web host. I'm a bit wary because of the "Where should this code live?" note here in the Django Tutorial:
Where should this code live?
If your background is in plain old PHP (with no use of modern frameworks), you’re probably used to putting code under the Web server’s document root (in a place such as /var/www). With Django, you don’t do that. It’s not a good idea to put any of this Python code within your Web server’s document root, because it risks the possibility that people may be able to view your code over the Web. That’s not good for security.
Put your code in some directory outside of the document root, such as /home/mycode.
My host told me that I'll be given a /home/ directory, and that the site will live in /home/www. I'm trying to emulate this directory structure on my end before I send everything to him to make sure it goes as smoothly as possible. My question is, if I want all my code to live outside of the /www directory (per the Django tutorial recommendation above), what actually goes inside the /www directory?
My development directory structure is basically this:
project
db
app1
app2
mysite (contains settings.py, wsgi.py, etc.)
static
templates (contains my base.html, and custom templates for admin, etc.)
Where app1 and app2 are Django apps I've developed to plug into mysite. So what folders / files need to go in the home/www directory, and what can safely live in home/mycode?
Your static and media (user-uploaded) folders, robots.txt etc. should be in the www directory. Basically any file that is directly served by your webserver and not through Django. Other files should live outside of this directory.
Your webserver should point all requests that are not found in the www directory towards your wsgi application, which doesn't need the code to be accessible by an url.
The reason for this is that your webserver does not execute the code in a python file, in contrast to php files. If your code lived in your web root, people could read your settings files by just going to example.com/src/settings.py. Images, plain html/text files and javascript should be read, but any code that should be executed should live outside your web root. Django will execute the files and generate the response that a user should actually see.
I know that it's not a good way to serve directly file and picture from django via views and urls dispatch, but if these files and pictures are served via the server (Apache), the whole world can see them. What if some files and pictures are private for the user, and only the connected user can see these files or pictures? In this case, I need to serve by django itself?
To serve private documents, you should use a Python view that does the security checks.
Here is an example.
If you are using Apache with mod_wsgi then you can use mod_xsendfile
You are essentially looking to run the authorisation for some resources via Django, pass a header back to Apache saying 'Hey dude, lighten up. This user is okay to access this' Apache will then handle returning the resource.
Rough steps (as in, rough enough that you will need to do a little more research using the links I provide as a starting point)
Apache needs to know which resources are public and which aren't. Create a sub directory under media for both of these types (Why not go crazxy and call them /media/public/ and /media/private/)
Set up an alias for the public directory and a WSGIScriptAlias for the protected dir, the protected alias will be pointing to your main site handler (probably django.wsgi)
Add settings to vhost:
XSendFile On
XSendFileAllowAbove On
Add an urlconf to your Django app that handles /media/protected/{whatever} and routes it through your auth Django app auth logic. An example of this is here
A useful snippet for the above is here
and another example for good measure here