My express application runs on the host, sometimes I see the syslog showing the following message:
log
but the application's router is:
router.get('/api/cart/products',PublicController.browse);
here is the application static path setting:
app.use(express.static(path.join(__dirname, 'public')));
i don't know why nginx is routing wrong path to public static directory.
Can anyone help me figure out what is the cause? thanks a lot?
It's hard to say without seeing more code or the structure of your folders. If you don't have the second line
app.use(express.static(path.join(__dirname, 'public')));
at the very end (it must come last after every other route) you will face issues. Have you made sure that this line of code comes after all your other routes?
Related
I installed fresh vue 3 app with cli, containing also vue router.
On my web I have put builded files into www/dist sub folder. Then in my php index file I linked all js/css files to /dist folder manually.
I have an image in component
<img class="discord-icon" src="#/assets/discord.png">
When I set publicHtml = '/dist' , everything works even image is shown, but for some reason my homepage gets redirected from original "www.page.com" to "www.page.com/dist"
I would like to have default "www.page.com" at homepage but also with working image, how can I achieve that ?
Edit :
My router config (default from Manual cli install with router)
const routes = [
{
path: "/",
name: "Home",
component: Home
}
]
const router = createRouter({
history: createWebHistory(process.env.BASE_URL),
routes
});
UPDATE :
On vue discord I got adviced to create .htaccess for this, sadly I am not skilled enough to create one, or even know to which folder store it. Also I had another one already in there since I am using php framework (Nette)
This is how I got it working for now :
"publicPath: '/dist'" and "history:
createWebHistory(process.env.BASE_URL)" where project is in "/dist"
folder, so page goes www.page.com/dist. All work but. I go to
"www.page.com" it redirects to "/dist" but when look in html it does
not generate "/dist/css/chunk-vendors.css" so all imported css is
missing. But when I hit refresh (going directly to www.page.com/dist)
chunk-vendors.css is loaded. By default vendors.css is not in
generated index.html so I guess its done by js. So i got evil thought
of just paste that vendors.css link manually to my production
index.html aand it works, althought when going to /dist url directly I
end up with loading this style 2 times lol. Then I got even more evil
thought and changed to 'history: createWebHistory("/")' , rebuilded
for production and now i have nice www.page.com and even all imported
styles are working (with that style link pasted in manually), just
have some feeling I will burn in hell.
Here is a little summary of how a vue-cli project usually gets built and pushed to a server. and what kind of config is important and what 's their purpose. hope it gives you an idea of how to setup your project.
Building with Vue Cli
This is how it works in a regular project to build with vue-cli:
vue.config.js
module.exports = {
publicPath: process.env.NODE_ENV === 'production' ? '/final-sub-folder' : '',
// ...
}
The above config sets a different site URL for dev and prod. The prod /final-sub-folder means that on the final URL in your distant server this sub-folder will be present (E.g. https://example.com/final-sub-folder).
when building with Vue Cli npm run build the output goes into /dist folder (by default) and the build is set for prod by default (so process.env.NODE_ENV = 'production').
Now, if you try to go in that dist folder in your localhost (on Apache for instance), the vue-router using the same publicPath will fail because on your localhost your-proj/dist is a different base URL than /final-sub-folder as set in the config. So it will only work in the final server where the base url can be matched.
Setting up vue-router
Your vue-router should always be set to (this config is for vue-router#next - for Vue 3):
const router = createRouter({
history: createWebHistory(process.env.BASE_URL),
routes
})
So that it follows the base URL you set in a single place, in your vue config.
(notes: the createWebHistory removes the # in the URLs)
Adding a .htaccess
Regarding the .htaccess, it is a common practice to set up redirections in it so that on your final server, accessing https://example.com/final-sub-folder/a-sub-page directly will be redirected to your index.html that can load the vue-router which will handle the route matching of what you entered in the URL.
https://router.vuejs.org/guide/essentials/history-mode.html#example-server-configurations
Without this .htaccess, the Vue router cannot be reached from a sub-folder since it does not exist on the server (it's a virtual route using rewriting engine), it would result in a not found URL.
Here is a simple example of .htaccess:
Options +FollowSymlinks
Options -Indexes
RewriteEngine On
RewriteRule \.(js|css|map|jpe?g|svg|gif|png|eot|ttf|woff2?)(\?.*)?$ - [NC,QSA,L]
RewriteRule .* index.html [NC,QSA,L]
What is important in that is the last line redirecting anything to index.html (which is generated from your vue-cli build).
The previous line allows any asset file to not be redirected (no asset file should be handled by vue-router).
Hope it helps you understand! ;)
I have a problem using Cypress when running tests on our staging domain. For some reason Cypres browser opens the correct website but then immediately changes the url to the absolute domain and appends __/ at the end:
https://stagingdomain.com/administrators/login becomes https://stagingdomain.com/__/
On production this does not happen, the test passes correctly. Sidenote: Our staging environment is only accessible behind our corporate VPN, but besides that everything else is the same
it('Gets, types and asserts', function () {
cy.visit('https://stagingdomain.com/administrators/login');
cy.contains('ADMIN LOGIN');
cy.url().should('include', 'administrators');
});
});
I have followed all security measures provided on Cypress' documentation but none seem to be resolving this issue. Wondering if anyone else has faced the same challenge and has been able to overcome it
Turns out this was a known issue with Cypress which was since addressed in version 3.4.1
This is still any issue in 5.1.0.
I clearly have a page redirect to index.php which is in http://url.com/site/
Instead of redirecting to http://url.com/site/index.php like it should. The page is redirected to http://url.com/__/index.php which does not exist. It seems to be an issue with the doc root rewrite.
I also tried adding these to my cypress.json with no luck:
{
"baseUrl": "http://url.com/site/index.php",
"experimentalSourceRewriting": true
}
As a workaround, I simply redirect the user again and they check if the session is valid by getting to my secure page after my login.
I've got to transfer a website from an hoster to another (MelbourneIT).
So I've done as usual with my favorite FileZilla, just copy the html website (without DB) to the other url.
So this one work for the first page ( http://www.lmhceramics.com/) because it's an html one but all my other pages doesn't work!
I've check the folders of my website and I found that this one worked with "Smarty" who is apparently a third party application.
I tried for 5 hours different things as : create an .htaccess to launch index.php instead of index.html, change the configuration on my site_globals.php but it didn't work. It looks like only the first page : index.html is loading.
I can give the access to the ftp if anyone could help it will be sweet as it's one website of my company!
Thanks guys.
Cheers
Initially I tested whether PHP was working, then when I was sure I looked at the error log. The overriding issue was a required library not being found because of a broken path, and PHP's display_errors setting was disabled so it resulted in a white screen.
The site main pages now function.
In site_globals.php, there were two paths that begun with a forward slash. This results in the code looking in the root directory of the server for a particular folder of files (the Smarty library, and the Smarty templates), which likely worked on the old server but not on the new shared hosting environment. New code italicised:
define( "SMARTYPATH", _$_SERVER['DOCUMENT_ROOT'] ._ "/deldridge_smarty/" );
define( "TEMPLATEPATH", _$_SERVER['DOCUMENT_ROOT'] ._ '/smarty/' );
Once that was fixed the code library and templates could be loaded and the rest of the configuration file continued to load. It then dies on:
$db_interface = new DBInterface;
$db_interface->connect( '172.20.254.1' , 'ampnet', 'cable05' );
This is an attempt to connect to a database. I haven't investigated what the database was for yet (that'd require looking through the PHP files in depth) but I'm assuming it was the login system or some such. Almost all of the pages in the site function with those two lines commented out, which I've done for now so that the majority of the content is available again. There's another reference to database connection details further down but they were already commented out.
One other area of particular interest is this:
// different dir structure on secure domain, make ammends
// ensure trailing slash if directory present
define( "SECURE_DIR", 'buildersbollards/' );
if ( $_SERVER['DOCUMENT_ROOT'] == '/home/deldridge/secure.4mation.com.au' )
{
$site_path = '/' . SECURE_DIR;
}
Hop that helps!
It's difficult to know with so little information. Enable error reporting in php or just look at the php error log in your server. One probable cause for the error 500 may be that some key folders don't have CHMOD permission to write; In smarty, for example, templates_c must be writable
I'm having trouble setting up a development workflow that will do both of the following tasks simultaneously:
Recompile static assets (js, css) on file change. Serve these static assets. Notify the browser that the page must reload whenever assets are changed. Use react-hot-loader.
Use express to run a server which serves an API which the static assets will "consume". Have this express server restart any time my server files change.
Is the best practice to have webpack-dev-server serve the static assets, and have a separate web server serve the API on a different port? If so, the API calls in the javascript will need to specify the host and port, and will need to be changed before going to production. It seems all the tutorials online focus on #1, and don't set up an API server. Can anyone point me in the correct direction?
I'm not opposed to using gulp and browserify or SystemJS instead of webpack, but it seems that if I want to use react-hot-loader, I need to use webpack.
You can do something like this:
Create an express() proxy
Create a webpack-dev-server
Link the assets with absolute url
Start both servers.
Note: Make sure to have different ports to run both the servers.
var proxy = require('proxy-middleware');
var express = require('express');
var url = require('url');
//----------------- Web Proxy--------------------
var app = express();
app.use('/assets', proxy(url.parse('http://localhost:8000/dist/assets')));
app.get('/api/url', function(req, res) {}
app.post('/api/url', function(req, res) {}
// ---------------Webpack-dev-server---------------------
var server = new WebpackDevServer(webpack(config), config.devServer);
// ---------------Run both servers-----------------------
server.listen(config.port, 'localhost', function(err) {});
app.listen(8080);
We have been using gulp+webpack for the last year and it has been great. We have an API Gateway which only serves up one static html file(the index.html) and everything else is just REST end points. Then in the index.html we reference a css file or two and a couple scripts that load from our CDN(Cloudfront).
If you run that way in production, your local setup just needs to use the webpack dev server as your "local CDN". You are correct, your javascript will need to know what the api url is since that will change local vs production. We actually have local, dev, stage, and production - once you have it setup to work in 2 environments its not hard to add more(which is good!)
Now our index.html has some template variables that get filled in by the API Gateway when it serves it up. Similar to this:
<script>
var siteConfig = {
apiBase: '<%=apiBaseUri%>',
cdnBase: '<%=cdnBaseUri%>'
};
</script>
<script src="<%=cdnBaseUri%>/assets/js/bundle.min.js"></script>
Then you just pull in siteConfig when your react app is starting up and prepend those variables to any api/cdn calls. Swap the variables depending on your environment, and bam, you're done!
A slightly simpler approach is instead of filling in those vars when the page is served up you could do it at build time. Thats how we started but as things evolved it turned out easier to manage at run time.
BTW, I am pretty sure you can accomplish all of this using just webpack - gulp probably isn't necessary but it was easier for us at the time to use gulp for running unit tests, linting, etc.
I need to setup intern to test ajax calls from a different server. I set everything up sort of following the official wiki in this address
https://github.com/theintern/intern/wiki/Using-Intern-to-unit-test-Ajax-calls
My config file has proxyUrl set to http://localhost:8080/sub
and http://localhost:8080/sub is setup as a reverse proxy to inter-runner in http://localhost:9000
When I run ./node_modules/.bin/intern-runner -config=tests/config from the tests root folder, the browser opens up and is able to request several files, until it tries to request the config file. That's when it receives a 404, because it requests the wrong address - http://localhost:8080/tests/config.js - without the sub folder.
I'm wondering if I'm missing something inside the config file, or if intern is not able to use proxies with subfolders. I tried to set the baseUrl parameter, but it had no effect.
Any ideas?
Update:
It seems that sometimes intern-runner uses the path provided in the config param, and sometimes it uses the one in the proxyUrl parameter inside the config file. As a workaround, what I did was to place the config file and the tests on 2 folders (actually I made a symbolic link). The first on tests/ and the second on sub/tests/ and ran it using ./node_modules/.bin/intern-runner -config=sub/tests/config.
It works, but it's kind of stupid and I really wished there was a better way to do it.
This is indeed a limitation/bug of intern. It assumes that the proxy sits at the root of the absolute domain name, i.e. that it has a pathname of /.
An issue has been created on intern's github repository here and the corresponding pull request that fixes the problem is here. Hopefully this gets merged into the upcoming 2.1 release of intern.