When using selfhost .Net Core 2.x, all the build artifacts are statically served by default, since the default directory is the same place as the binary/exe.
This means if one knows the names of the dlls, they can just request
them at /Whatever.dll, or they can also get any config files by name,
i.e. appSettings.
If you change things so that that the root directory is different or that directory is not in the VFS, /metadata stops working.
Is it possible to have /metadata work, but not allow the service's dlls etc to be statically served?
I have tried restricting the paths. This will keep settings / dlls / exes from serving, but the /metadata page will come up completely blank.
The /metadata page isn't related to the static file directory location, you may have caused a Startup Exception that's impacted how it works. If you can put together a stand-alone project on GitHub which shows the issue I can investigate.
Only extensions in Config.AllowFileExtensions can be served, you can remove .dll from being served with:
Config.AllowFileExtensions.Remove("dll");
.exe aren't servable by default, if you can download them you might be downloading them with .NET Core's static file handler instead.
It's common practice to have the WebRoot outside of the project root which for .NET Core is typically /wwwroot.
edit: Updated suggestion to remove the badness.
What I ended up doing at first was to add a .UseWebRoot() onto the
builder, then later switched from the selfhost ServiceStack template
to the web template per Mythz's suggestion. The web template was
set up in a way that solved my problem.
Thanks again.
Related
for example, there is an application written using dot net core 2.1
Published under the IIS (Windows Server 2016). At the root of the application (near to the binaries (.dll)) random files are being created and modified. Will this affect the performance of the application? Will it make a difference if these files are created in a subdirectory next to the binaries?
If we exclude IIS and host under Kestrel, will it affect somehow?
As far as I remember, when hosting applications, written on a .NET fullframework, under IIS, and modifying any file (for example, a text file) in the BIN directory resulted in restarting the web application.
I do not know what files are being created and modified i would separate them form the app files for security reasons to say the least. Having said that to answer your question.
It should not affect the performance unless the volume of operations is so large that it will use up all iops on the drive or the pc/ram of the machine.
Kestrel will not be affected unless you try to modify files that kestrel uses for the app in some way and if you use dotnet watch run it will try to recompile them and run in the host if not it will ignore their existence until the host is restarted.
IIS should ignore them as well but i do not know what will happen if you have those files in bin and try to restart the host. i have tried changing and adding a file and did not restart. Maybe there is something in IIS settings but since i have not setup our IIS my answer is lacking in that regard.
So I know this exists as I had found it recently after core was announced, and I have actually done it in the past. I just cannot remember a specific file name.
When Asp.Net Core 1.0 or 1.1 was out, there was a feature in the IIS module that would watch the root directory for a special .html file with a certain name.
If that file appeared, it would shutdown the Core app, and serve that HTML file. This enabled you to cleanly upgrade without having to find and kill processes. When the upgrade was done, you remove the file and the process starts.
I cant remember the required filename
I'm also not sure that this feature has been included in newer versions of the aspNetCore IIS module.
Anybody remember this?
It is well documented as app_offline.htm,
https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/aspnet-core-module?view=aspnetcore-2.1#app_offlinehtm
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
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.
I'm dealing with an issue where there was a site setup, and the default.htm used an iframe which pointed to an ASP directory. It seems like the ASP directory isn't readable and not processed - is there anything special that needs to be done to the ASP directory like permissions-wise?
wwwroot/sitename
<iframe src="ASP/file.asp"></iframe>
wwwroot/sitename/ASP/file.asp exists, and several other asp files but they aren't getting referenced by the iframe.
Update: I'm getting a 404..
The page cannot be found
I think I have to create a virtual directory and name it ASP. I never use IIS though - does anyone know how this works? And would I need to restart IIS after creating the virtual directory?
Update #2: More info..
Execute permissions: Scripts Only
Application name: asp
For Authentication Methods, "Integrated Windows authentication" is checked
Local Path: Read
Update #3: I can access asp/file.htm file fine. Can anyone provide code for a simple test I could do to see if its working properly ( I have no ASP/VBScript experience )..
one of the top of the pages contains <%# LANGUAGE="VBSCRIPT"%>
Is this IIS6 by any chance? In IIS, under Web Sites there is a folder called Web Service Extensions. Make sure Active Server Pages are set to Allow and not Prohibited!
When you create a virtual directory for an ASP site in IIS, you have to make sure it is allowed to execute scripts. What version of IIS are you using? In 5.0 and 6.0, there should be a checkbox Run Scripts (such as ASP). Make sure that's checked.
Try putting a test.html file in the root directory of the site and then try to open it through wwwroot/sitename/asp/test.html - .html files won't be processed by asp.dll and so should display if the site is setup correctly even if there is some kind of asp.dll problem.
If you can't see a html file then I guess you will need to configure the website in IIS (not sure if a virtual directory is necessary from the information given) - check the 'home' tab to see if the path to the application is correct first.
If you can see the html file then I'd guess that asp is not properly installed (but that is a guess).