I've built a Node.js app locally that works fine but when I went to test it on Bluemix, it didn't show the app consistently. What I mean is this. I did my cf push. It reported it went up ok. I went to my domain and I saw the original, default BM Node.js 'hello' page. I shift reloaded a few times and sometimes I saw my content. Sometimes I saw my HTML and not the CSS. But more often then not I saw the initial BM hello page stuff. It's like there is some serious caching going on the BM side but I do not know how to clear it.
As I said, cf push is reporting everything ok as far as I can see. The File browser in the dashboard is showing old files as well.
Well, this was stupid, but I honestly see this as a mistake others can make too so I'll fess up with what I did. My app had "recognition" in the name, and when I created the app I misspelled it as "recognation". So when I did my push it ended up making another app, and I had multiple apps with the same route which apparently confused Bluemix, understandably so I think.
So I guess the take away is - ensure you get the darn app name correct when creating and doing your push. :)
Related
I have a Azure App Service app that I'm trying to get deployed.
Today I ran into an issue where .NET informed me (via the yellow screen of death when I browse to the URL of my app) that I had a missing DLL (for the purposes of this question I don't think it really matters).
I used FileZilla to publish my changes in an attempt to do a manual deployment first and then work my way to automate it.
After so many attempts to fix it I later realized that the error message never changed. I did something more severe and renamed my bin folder into something completely different and the exact same error message would appear.
I've stopped the service, restarted it, and as mentioned, renamed folders, etc. and still the exact same error message persisted.
I also decided to open up the Azure Portal Console for my App Service app to browse a bit and to my amazement, nothing seemed to have reflected at all. The FTP shows one thing and the Console shows another.
Would anyone have any idea as to why this is happening?
I eventually got it to work and I will share what I tried.
I deleted the web app and created it again (I found this to be important the first time around). This was quite time consuming and did help but it wasn't long before the same problem happened again.
Then I finally found a solution that seems to give me consistent results:
I kept on editing the Web.config which seems to force a recompile and clear some sort of cache. So each time the web app stopped updating, I would make a slight change in the Web.config, upload it via FTP and the app finally updates.
If anyone has any more details on this, it would be greatly appreciated.
I just started using laravel's lumen and managed to make it work both locally and on a server, when I was about to start exploring it, my index.php consisted in just:
$app = require __DIR__."/../lumenTest/bootstrap/app.php";
$app->run($app->make('request'));
echo $myundefinedvariable;
Which displays a ErrorException: Undefined variable: myundefinedvariable, but inside the "...at Application->Laravel\Lumen\Concerns{closure}" window I can see a giant wall of text with stuff like:
... 'APP_KEY' => 'fake0BqKgHeC72EmT7039B6pDCsJ90key' , ..., 'DB_PASSWORD' => 'secret', ...
And my first thoughts were, maybe it is because im running it localy with XAMPP or something, so I went and tried it on the server and the same thing happened.
Is it normal that sensitive data from my .env file gets shown to everyone after doing any php error?
Is there a way to avoid this happening? (different than not having any PHP errors, because I tend to have them a lot).
Additional info:
PHP version 7.1.12
Lumen (5.6.1) (Laravel Components 5.6.*)
The directory "lumenTest" is one level above my www or public and there is where the .env is located, the site is on a Linux server shared host
No, that's not normal. Professional developers consider this an amaturistic behavior. That's the exact reason why companies don't even consider using Laravel.
Many people (including me) already notified them that this is really not-done, but the developers don't really seem to care. In fact it's the only framework in the world that thinks it's OK to print critical information in a debug page. Surely a visitor should never see stack traces, sql queries, pieces of code... But environment variables are confidential and should never end up in a HTTP response.
The best advice I have is to use a professional MVC framework like ASP.net, codeigniter, or yii, since there's no telling what the Laravel devs also think is OK to do...
If on the other hand you do decide to use Laravel anyway, there's a package that counters this: https://github.com/GlaivePro/Hidevara
It's real easy to setup, just make sure you don't forget the app->extend instruction.
On a production server you must not run "composer install" but instead "composer instal --no-dev". This way filp/whoops will (should, hopefully) not be installed and cannot be triggered.
For professional development, i surely recommend not to use Laravel since the bar of what they think is acceptable seems to be very low.
As a sidenote: the developers claim that nothing can go wrong when APP_DEBUG=false, but incidents in the past have shown that the whoops handler can be triggered when debug mode is disabled. https://www.google.com/amp/s/blog.hacken.io/dangers-of-laravel-debug-mode-enabled%3fhs_amp=true
Yes, if you have debug mode enabled, any sort of data relating to an error can be displayed. This certainly would include sensitive data that would be useful when debugging.
For production, you want all errors to be privately logged, not publicly displayed. For this reason, you will want debug=false in your .env file.
If this is happening while debug mode is already set to false, you will want to configure the hiding/logging of errors at the server level.
I'm making an app in the Cloud9 IDE using Node.js with the Express.js framework. Something very odd is happening to a specific .ejs file where if I try to update it (like typing some mumbo jumbo in an h1 tag and then saving and restarting the server), it NEVER gets reflected in the browser no matter what I do. For example, if I delete my jumbotron, save, restart the server, and then refresh the browser, I still see the same page with the jumbotron. I also tried deleting this entire file and then restarting the server and I still see the page and it doesn't break my application which is bizarre. All other .ejs files are fine and I can see the changes that I make.
I've spent about 4 hours trying to figure this out and no one else seems to have my specific issue. I tried clearing my browser cache, using different browsers, logging in/out from Cloud9, creating a new database, going back to older versions of my code, etc. and nothing seems to be working. I'm not even sure what code to post on here since my entire app is about 2000 lines of code so far. Does anyone have any suggestions because this is really frustrating.
OK, I've created an Azure Mobile Services project in Visual Studio 2013.
I run it up as-is, then in the browser I test it by adding a todo item via the simple browser app that seems to get baked into these service projects. It gives me a '201 success' message - brilliant.
I then convert the project from IIS Express to Local IIS as the web host, recompile and try again, and although I get the same smiley face app telling me that everything is OK, when I try and add a todo item I get a 404 error. This is contrary to the Microsoft article that gives these instructions, which clearly says I am able to choose either IIS Express or Local IIS when setting up the project.
My guess is that web.config is missing something when this project runs on the local IIS server.
I'm hoping someone already has a solution before I spend hours trying to work out how to configure IIS for this type of project.
I've already wasted a load of time working through loads of bugs and gotchas with Azure Mobile, and I'm starting to run out of steam - so I'm hoping someone can help me before I go and grab an account at Parse.com
Many thanks in anticipation.
Dean
The easiest approach for your situation might be to just deploy to the cloud, and use that service for your testing. Visual Studio 2013 Update 2 makes it easy to deploy your app and connect to it for remote debugging. It is a little slower than using a local instance, but you are also assured that there will be no surprises when you eventually go live (since you are live the whole time).
That said, we will investigate the issue you are seeing with using IIS directly. Some things you might want to try on your own:
Verify that you can view the web side from your Mac's browser, to make sure that the firewall is letting the requests through.
Try using the "Getting Starting" link from the smiley-face page, to see if the REST endpoints are behaving correctly.
I've found plenty of versions of this questions, but neither seem to go further than an apparent Google Chrome bug.
What happens is that whenever I copy a codeigniter setup to a new folder on my server, to start a new project based on it, I get "no data received" in any browser I try it on.
The strange part is that the problem is solved if I go into each file that gets include()-d, add or change something irrelevant (like a blank space) and save the file. I don't know why, but this makes that specific include() work. Otherwise, the script stops before it.
There's nothing logged in the server's access or error logs so I can't figure out what the problem might be.
Needless to say this has been driving me crazy. Any suggestions?
Thanks!
My sysadmin figured it out. It was related to system wide APC cache. I used apc_clear_cache() at the top of index.php and everything works like a charm!