Setting root path to rails app's root_path in nginx - ruby-on-rails-4

I've configured a rails app on Digital Ocean (DO) using passenger, nginx and capistrano. Everything is working fine expect that I want to get the application's root_path page to be displayed whenever I go to the website. But that's not the case. I've to keep another page index.html in public directory and set it to root like:
xyz.conf file
root /home/user/apps/xyz/current/public;
I don't want this extra static page to be displayed. It just doesn't look good. Instead I want the application's root page which I specified in routes.rb file like root 'controller#method' to be displayed.
I've tried removing root line or restricting it to just /home/user/apps/xyz/current in .conf file but that just gives a 403 Forbidden error which should be the case.
I've thought a lot but can't think of anything. Anyone out there who had a similar problem and managed to figure it out?

Your nginx root is must be like:
root /home/rails/sample_tasks/public;
Note: path may vary but you need to set path till your app's public folder
then reload you Nginx
service nginx reload

Related

How to Configure django_plotly_dash to serve assets from custom url

I have an hybrid app with most pages being on vuejs but some legacy code pages are still being served through dash-django app.
previously it was wholly a dash app.
on the production environment this is being served through an nginx with dedicated static directory and a reverse proxy.
The app is being served on a subdomain.
So the url looks like :
abd.com/subdom/route_to_app_endpoints
where abd.com is set to serve nginx files from base directory
and abd.com/subdom is reverse proxy to serve files from port 8000 on which the django application is running.
The problem I'm facing is when the app loads the base url i tries to load the components and the layout from is hitting the root directory :
eg for
abd.com/.django_plotly_dash/app/FileUpload/_dash-layout and it
gives 404 not found. This is what it tries by default .
whereas if i request
abd.com/subdom/django_plotly_dash/app/FileUpload/_dash-layout my
browser gives a nice output ..
I tried setting :
PLOTLY_DASH = {
"requests_pathname_prefix" :"/subdom/"
}
in the settings.py but still it is unable to route properly.

Rewrite folder name from the URL in nginx

Hi I am new to nginx and trying to remove folder name from the URL.
Here is how my URL is accessible:
localhost/project_name/frontend/dashboard
localhost/project_name/frontend/feed
I want to remove the folder named 'frontend' from the URL. the folder contains all of my rendering templates. I have used following configuration but I get 404 when I enter the URL in browser after this configuration:
location /project_name/frontend {
try_files $uri $uri/frontend /project_name/ #extensionless-php;
}
I am not sure whether the configuration is correct, I have tried several configurations but none of them helps.
P.S: This is my just first day on nginx, so pardon if I miss something very obvious.
Thank your for your help.

How to Handle Incomplete Django/Nginx File Server URLs?

I have a Django website that uses Nginx on a separate file server to serve up images uploaded by my users. When any user views another user's photos, the link to the photo will have this structure:
https://fs01.mysite.com/media/photos/<username>_<photo-id>.jpg
When the page is rendered, the user's photo is served up by the file server (fs). But what is the Nginx way of handling incomplete (one could also say incorrect) requests to subdirectories of the above URL? For example, if a user enters this URL:
https://fs01.mysite.com
...they see Nginx's default "Welcome to nginx on ..." page. If they enter this URL:
https://fs01.mysite.com/media
...they'll get the Nginx "404 Not Found" page. And if they enter this URL:
https://fs01.mysite.com/media/photos
...they'll get the Nginx "403 Forbidden" page.
How do you handle these situations in Nginx?
They see welcome page, because the nginx matches default vhost entry instead of yours. You should probably delete the default one (/etc/nginx/conf.d/default or /etc/nginx/sites-enabled/default, depending on the linux distribution you use) and make sure that server_name line matches your url (i.e. no slash at the end).
Looks like your location block matckes only media/ (with the slash at the end). Thats why you get 404 error - it matches different location block and is probably handled by Django.
You are not allowed to list the directory, so you get the Forbidden error.
I think that it is up to you how such cases are handled, just make them consistent. Make sure that you understand nginx configuration and the pathways different requests take. To avoid 403 error, you can put empty index.html file in that directory.

ember cli url not working on server with manual return key (versus link-to)

An ember cli site was deployed onto a server and it works fine. Links via {{link-to}} all work beautifully.
BUT, when a user (me that is) manually enters a url and hits return. then the site is not found.
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
even changing a parameter of a working url (initially navigated to thru link-to)
http://site/start/0/length/30
and simply backspacing, changing the 30 to 20 and hit return
http://site/start/0/length/20
its a no go
localhost:4200 doesn't have this issue.
has anyone observed this vicious behaviour.
i actually need it for a callback redirect for oauth. but then noticed than any manually entered urls dont function.
It is because your server (IIS?) is trying to access the full path requested by your browser (eg /start/0/length/30), and not finding a valid file on disk returns a 404.
So, you need to configure your web server to proxy/rewrite the requests to the proper location. Assuming you are deploying your application in your "root" directory, the proper location is /index.html (the file ember-cli creates).
Unfortunately, I can't help you with IIS, but I can provide you with the proper configuration for nginx:
location / {
try_files $uri $uri/ /index.html;
}
This says "If the requested URI doesn't exist, instead respond with the /index.html file".
When you are using ember server on localhost:4200 you don't have the same problem because it is automatically doing something similar transparently.
If you are serving this up from any web server that isn't the built in Ember, ie non local server, you need to have a wildcard rule that returns your Ember app's index.html file for anything below your websites base url. If you only have your base url return the index.html file, then your webserver is confused by the unrecognized url and thinks it has nothing to return. If your rule, though,
for baseUrl/* returns index.html, your Ember app will then run the correct route hooks to establish the app context
this is a dupe and the question is
How to run emberJS application in IIS?
the easy answer is set locationType: hash in ember-cli's environment.config file (copied from accepted answer)
that will introduce a '#' in the url but doesnt require an IIS change.
var ENV = {
...
locationType: 'hash'
... };

Select the default Artifact/Bundle to show for '/' in a Virgo/OSGi/Jetty Environment

Sorry if this is a bit noobish, but I've never done Jetty config, let alone in an OSGi environment.
I'm to make a specific URL show /ui/dcx/ by default.
I have looked at all the config files I've found for Jetty and Virgo and don't see where this default is configured.
It always redirects http://localhost:9080 to http://localhost:9080/splash.
I have even tried removing the splash bundle from the pickup directory, but the redirect still happens.
Does anyone know where the setting for default URL or default bundle is?
Looking at Virgo server it appears that /pickup/org.eclipse.virgo.apps.splash-3.5.0.RELEASE.jar is bound to contextRoot of '/' (Web-ContextPath: /) and the welcome-file element of web.xml is bound to index.html which inturn has a meta refresh for '/splash'.
So to change that to /ui/dcx/ you would need to remove the splash bundle and have your bundle bound to contextRoot '/' and then in turn follow the same approach as used by the splash bundle.