Using Kentico 9, while I was away it appeared that something changed! While our production site appears to be working fine our staging site is not. When I try to access the staging site it is unable to "find" any of the related CSS or JS files and therefore displays the site without any of those files. Another part of the problem is that the same thing is happening in the admin portal and since the admin portal relies on those CSS and JS files to work I can't troubleshoot there.
When I try to get to the resource directly in a browser: e.g. iddba-staging.azurewebsites.net/CMSPages/GetResource.ashx?stylesheetfile=/App_Themes/Default/bootstrap.css it fails.
When I try to access it directly at the prod site: www.iddba.org/CMSPages/GetResource.ashx?stylesheetfile=/App_Themes/Default/bootstrap.css as I would expect it provides me the opportunity to save the file.
Our site(s) are hosted in Azure.
Any idea of where to turn next? Thanks.
Also on a possibly unrelated note, I have also noticed an error in the logs on staging that is not on prod:
.NET Runtime version 4.0.30319.0 - Loading profiler failed. Failed trying to receive from out of process a request to attach a profiler.
Not sure if this might be related. Thanks.
Once I realized that getresource.aspx was a dynamic file and the css and js files were either already in the database or were in respective directories it looked at the dlls that power Kentico. In this case I decided to see if there were any differences in the bin directories of prod and staging. I don't know how they became out of sync but they had. Since the problems I had appeared to be serving up CSS files I noted that one file CMS.LessCss.dll was in prod and not in staging so I copied that file in. As soon as that file was copied Kentico threw an error with the word Jurassic in it (odd!). I found a file Jurassic.dll that was in Prod and not in Staging so I moved it.
Voila! The site was back, serving CSS and JS files on the front end and in administration. We are still clicking through all our pages to see if anything else is not working but for now we are good and if I have any further questions I will look in bin first since there are still files that live in prod that are not in staging and I don't want to re-populate unnecessary files. I am just not sure how the directories got out of sync in the first place... or at least no one here has admitted to having messed around! Yet.
Thanks for all your help.
Related
Ok, I have never seen anything like this before and hoping someone else has. I just finished patching our Dev and Test servers to Nov2017CU (SharePoint 2013). Since then, any solutions that are using JS injection from Site Assets are not updating. I'll make a change to the file, the library reflects that I made the change, but when I attempt to load the page accessing the js file, the changes are not reflected. Hard refreshes and full cache cleans are not affecting it. If I close and reopen my editor (VSCode) my changes are gone. When I look at the version history, the current version doesn't have my changes, but the previous version does. If I try to revert to that version, it doesn't take (still shows the previous version of the file).
Here's where it becomes extra weird. I have deleted the entire file from the library. Reset IIS (heck, I even rebooted the server at one time). It somehow still loads the file. The file is no longer in the library, but the server is still serving it up to the browser. I have confirmed it is not getting it from another location as the Dev tools are showing the file is located in the Asset Library the file was deleted from. Even users who have never accessed the site before are still getting that file in their browser.
This isn't limited to a single site either. I have other developers in different sub sites (same site collection) that are having the same issues.
Anyone seen this before?
Looks like your web application has BLOB cache enabled which is causing files to served from the cache.
There are 2 ways to fix:
1) The heavy handed way would be to flush the BLOB cache using powershell commands mentioned:
$webApp = Get-SPWebApplication "<WebApplicationURL>"
[Microsoft.SharePoint.Publishing.PublishingCache]::FlushBlobCache($webApp)
This will flush all the files in the BLOB. Usually, the files are cached based on the max-age attribute value. So, that is the reason that your files are being served even if you had deleted it from the source.
2) The surgical knife approach would be to append a query string, like (https://sitecollurl/siteassets/app.js?v=1.1), to the file references (usually in master page, page layouts, webpart references, script links etc. wherever it is referenced). When you append a query string to the file, it will force the browser to download the newer version of the file. Would prefer this approach as it will not unnecessarily clear other files from BLOB.
I am working on a project that has us deploying to an Azure Web Site.
The code is overall working and now we are focusing more on security.
Right now we are having an issue that back end configuration files are visible with the direct URL.
Examples (Link won't work):
https://myapplication.azurewebsite.net/foldername/FileName.xml (this
file is in a folder that is contained within the root application)
https://myapplication.azurewebsite.net/vApp/FileName.css (this file
is a part of virtual application sub folder)
I have found this to be true with multiple extensions and locations.
Extensions like:
.css
.htm
.xml
.html
the list likely goes on
I understand that certain files are downloaded to the client side and that those can't be stopped. However backend XML files are something we don't pass to the client (especially if has connection strings).
I did read a similar article, Azure App Service Instrumentation Profiling?
However this didn't directly relate to my issue.
Any insight would extremely helpful.
Do not store sensitive information in flat files, especially under your site root. Even if you web.config it just right you're still one botched commit away from disaster.
Use Application Settings instead, that's what they're for.
https://learn.microsoft.com/en-us/azure/app-service-web/web-sites-configure
A few months ago, I was making changes to this web application for a client. It's a JSP web application with tomcat as the web server. I've made the changes, tested it (of course), and left the application to the client's hands. They have come back to me and mentioned that a specific area of the website is not working. I go in and check the area, indeed it wasn't working but it was working a few months ago when I made the changes.
The issue encountering a very unusual. Every page in the directory in question (/tomcat/webapps/website/english/login) throws a java.lang.ClassNotFoundException.
To troubleshoot the issue, I've tried creating a blank JSP with "hello world" and no coding and still throws a java.lang.ClassNotFoundException. I create the same JSP page outside of this directory and it is fine
Steps taken to replicate this issue:
I enter into the directory in question (tomcat/webapps/website/english/login)
Create a JSP page called test.jsp that literally has "hello world" only (no coding)
On the browser, I navigate to test.jsp. It throws a java.lang.ClassNotFoundException
I enter into the directory one up from login (tomcat/webapps/website/english)
Create a JSP page called test2.jsp that literally has "hello world" only (no coding)
On the browser, I navigate to the test2.jsp page. It works
I've done other test but could not find the issue. See below for some methods performed
Moved the web application into a different directory (tomcat/webapps/website2). Everything, including the /english/login directory, works
Deleted the web application directory and recreated the directory path, still giving me the exception
Checked permissions. The directory in question has the same permissions as everything else in the web application (including the files)
With the results from the tests, I believe the issue is the directory itself (/tomcat/webapps/english/login). Everytime I move the directory, everything works.
Mind you that I was making changes to the web application using a text editor (notepad++) not on eclipse, building the application using TeamCity (which compiled fine), the server runs under linux and I have no access to the build script but I believe ANT is used as the builder
So my question is, what is causing this issue? To have all the files in a specific directory to look for a class?
Any clues/help is much appreciated. I've been working on this problem for a few days. It's mind boggling
Cheers!
I would check the class path being used with PS -ef and look for the process. The error logs should point to a specific class. Those two clues can help determine if is config or war issue.
A possibility that I have seen is that in a tomcat config file, the paths allowed are explicitly defined. Also, a config file could map a specific path to a java class.
Found the answer to my own problem. The issue originates in Tomcat. The web server converts the JSP file into a .java file then compiles it. For some odd reason, Tomcat was not doing this for all my files in a specific folder.
Solution is to go into Tomcat's work folder, drill down until you see your webapp's name and delete the folder. This will force Tomcat to rebuild all the visited pages.
A safer way (which didn't work for me. Did not delete the webapp in the work folder) is to log into Tomcat and undeploy the webapp all together. This should delete the webapp folder in the work folder of tomcat.
Hope this helps for those experiencing similar issues
I am working through the example in the Liferay documentation; I have created and built the little greeting applet and gotten no errors at compile or build. I don't get any errors at deployment, either, but the application is showing up.
The deployment says it is copying my war file to portal-dir/deploy. I have determined that I can copy the war file there, though something (I guess in the server) removes it after a few seconds. But when I go to look at it in a browser off my local server, it is not there.
Does anyone know what I should look at to fix this?
No need to fix anything here -this is how autodeployment works. Web archives found in deploy directory are removed from there, extracted, processed by Liferay and in the end you should be able to find them in ${catalina.home}\webapps (assuming that you're using a Tomcat bundle).
I'm using multiple computers for development and I want to be able to store my files in my dropbox folder. I went to change the physical path in IIS from c:\inetpup\wwwroot to the dropbox folder but I get this error:
The requested page cannot be accessed
because the related configuration data
for the page is invalid.
I couldn't find the config file so I was wondering if anyone had done this before or whether there a better way to sync everything nicely across several PCs?
I tried it (IIS 7.5, Win 7) and it should work just fine to let your physical path of your web look at your dropfox folder. I would guess your web.config file generally contains malformed XML (see KB942055).
I'd suggest, try to map it to an empty folder just with an index.html file and see if this error still occurs.
As a workaround, I guess you can put Dropbox in your wwwroot folder and set up a virtual directory that points to Dropbox. However, there are some security issues that may hinder you from doing so. I come across a nice tutorial on how to set up Dropbox to IIS as FTP Publishing. Hope it helps.
Hodgin's guide on using Dropbox as FTP publishing.