Every time I publish my project my folder permissons get removed. My project requires IIS APPPOOL\appPoolName and IUSR to have specific access right to specific folders.
Whats the best way to apply the folder permissons after the artifact has been published?
Not sure if totally get your point. You can use location elements in the web.config file, there is a lot of information on the web about that - this gives you a start: HOW TO: Control Authorization Permissions in an ASP.NET Application
Besides, for folder NTFS permissions here rather than web security permissions. You could also add a custom target to Visual Studio's web publishing pipeline. For detail ways please take a look at what Sayed Ibrahim Hashimi does here.
Related
I have written a GitHub app that requests permissions for all repository contents.
The app basically reads a spec file that I created in order to do some custom logic.
The spec file can be located in any folder that the installer wants and therefore I ask for the elevated permissions.
For security reasons, I need the Github App to only have permissions to the specific file and not the entire repository contents.
Let's say I have 2 installations:
Installation one will request permissions just to some/path/to/folder/service.yml
Installation two will request permissions just to service.yml
I couldn't find any way to do so, not in the api of the installer, and not at the GitHub app level.
I thought about some workarounds using symlinks but it does not satisfy the requirement.
I am trying to create a release pipeline in Azure DevOps. We already have a functioning build pipeline that works well, it is able to package the build with VSBuild and publish it as an artifact. Then in the release pipeline I am using an IIS Deployment job (which includes IIS Manage and IIS Deploy tasks) and it gets that artifact to deploy.
The problem is that we already have a publish profile (.pubxml) that should take care of pretty much everything the IIS Deployment is doing (at least as far I as I understand it). So to me it seems I have two options that don't require me to refactor the project configuration itself.
I can try to mimic the settings on the IIS Deployment job to match our .pubxml as closely as possible and manually applying any changes that aren't doable through the task settings. Obviously this is not ideal as that would require us to update both when ever we make changes and it introduces a large chance of the pipeline breaking down over time.
I can scrap the idea of using IIS Deployment and just use a VSBuild task that uses arguments /p:DeployOnBuild=true /p:PublishProfile=Staging. This doesn't seem like best practices because it means my release pipeline isn't passing a build package to deploy, it is just creating a new one at each stage.
So is there a better option that would allow me to utilize the package I created with VSBuild and the .pubxml configuration together in a deploy? If that isn't possible then are either of my options the "correct" way to handle my situation or am I just missing another method of deployment I could use?
Thank you for any help or insight you can provide. Please let me know if there is any more information I can give that would be useful.
You can try using publish settings file (*.publishsettings) for your IIS deployment.
A publish settings file (.publishsettings) is different than a publishing profile (.pubxml) created in Visual Studio. A publish settings file is created by IIS or Azure App Service, or it can be manually created, and then it can be imported into Visual Studio.
To view more details, you can see:
Publish an application to IIS by importing publish settings in Visual Studio
Deploy your app to a folder, IIS, Azure, or another destination
So unfortunately there doesn't seem to be a way I can achieve everything I wanted in this. The publish profiles are required for when we build the project so without making changes to how we configure those I need to build the project whenever I want to deploy. Ultimately I went with option #2. I essentially just copied most of the build tasks used in the testing pipeline and placed those in the release pipeline with a few modified commands to actually deploy the build once finished. It all seems to work just fine but still doesn't feel like best practices. If I am missing something please let me know and I will make updates as appropriate.
I am building a very small Node/Express API app in Azure using Twilio to route communication for a small group. I initially built out a data structure for users in CosmosDB but found out it's minimum $24 per month, which is way over budget for something that will likely hold 20 or so records. Because of this, is seems much more reasonable to just build this into a json file that sits in a ./json subfolder. However, it has occurred to me that whenever I deploy, I would be overwriting this file with the default file I have locally. I have been working via the Azure App Service tool in Visual Studio Code and can't figure out a way to make it ignore the file.
I can go into Kudu and copy the file down each time before I deploy, but I will eventually forget and this sounds like a very brittle process.
I added a json/ line to .gitignore, but that has no effect on the deployment (as expected).
I also added "appService.zipIgnorePattern": ["json{,/**}"] to the settings.json file, but instead of just ignoring that folder on the server, it erases it on deploy (the zip ignores it and then it wipes/replaces the whole wwwsite folder). Looking for the file gives me {"Message":"'D:\\home\\site\\wwwroot\\json\\users.json' not found."}
I was hoping there is a setting that would deploy, replacing all folders in the package, and ignoring all content in the ./json folder. Does this exist?
Alternative solution, 2021:
Instead of excluding folders, select the folder that you do want to deploy. Data in other folders will not be affected.
Deploy from: edit .vscode/settings.json in your local project and add "appService.deploySubpath": "./folderToDeploy"
Deploy to: In the Azure Portal go to your app service. Under Configuration / Application Settings add a new Application Setting with name SCM_TARGET_PATH and value ./folderToDeployTo
Using VS Code right+click deploy will deploy the contents of the folder. I was able to work around this by adding Azure as a remote branch and using .gitignore. I placed my json file inside a random folder (content/json) then placed /content/json in my .gitignore file.
The company I work for currently has several projects in TFS 2015, each with their own build definitions.
We are in the process of transitioning from TFS to VSTS.
One of the features of VSTS that we were trying to utilize in the builds is the Secure Files in the projects' Library, to store the certificate issued by our company used for digitally signing assets in different installers.
It is currently duplicated in each project.
We were planning on uploading the certificate to one project and then use the 'Download Secure File' task in all of the projects' builds (that need it), to eliminate the maintenance of having the same certificate in multiple projects.
Not surprisingly, after uploading to one project, the file is not listed in any other project's Library or available for download as part of the build, even if I try to assign the project(s)/team(s) as a security role to the secure file (even giving it Administrator role).
Is there a way to have a secure file in one project's Library be shared across other projects, so that it can be downloaded as part of a build task?
It's not a big secret that the VSTS team has been working towards making individual projects portable. To allow you to take a project, with all that belongs to it, and then move it to another account. No clue when or even if this will ever be released, but it serves as a basis behind some of the separation between separate team projects.
In order to make this seamless, direct links and dependencies between projects are actively being discouraged and old features that are cross-project are slowly disappearing from the UI (even if the API supports it in many cases).
I suspect that if you configure the builds scope to be "Collection" that the REST API will be able to access the secret file from the other project, but it would require a custom task.
The guidance would be to replicate the secret file to each team project that needs access to it.
I have a Windows Azure Website and I've setup Azure Continuous Integration with hosted Team Foundation Server. I make a change on my local copy, commit to TFS, and it gets published to Azure. This is great, the problem is that I have an Access database in the ~\App_Data\ folder and when I check-in the copy on Azure gets overwritten.
I setup a web-deploy publish profile to "Exclude App_Data" and configured the build task to use the web-deploy profile, and now it DELETES my ~\App_Data\ folder.
Is there a way to configure Azure Continuous Integration to deploy everything and leave the App_Data alone?
I use the 'Publish Web' tool within Visual Studio, but I think the principles are the same:
if you modify a file locally and publish, it will overwrite whatever's on the web
if you have no file locally - but the file exists on the web - it will still exist on the web after publishing
The App_Data folder gets no special treatment in this behaviour by default. Which makes sense - if you modified an .aspx or .jpg file locally, you would want the latest version to go on the web, right?
I also use App_Data to store some files which I want the web server (ASP.NET code) to modify and have it stay current on the web.
The solution is to:
Allow the web publishing to upload App_Data, no exclusions.
Don't store files in App_Data (locally) that you want to modify on the web.
Let the web server be in charge of creating and modifying the files exclusively.
Ideally you would not have to change any code and the server can create a blank file if necessary to get started.
However if you must start off with some content, say, a new blank .mdf file, you could do the following:
Locally/in source repository, create App_Data/blank.mdf (this is going to be a starting point, not the working file).
In Global.asax, modify "Application_Start" to create the real working .mdf file from the blank starting file:
// If the real file doesn't exist yet (first run),
// then create it using a copy of the placeholder.
// If it exists then we re-use the existing file.
string real_file = HttpContext.Current.Server.MapPath("~/App_Data/working.mdf");
if (!File.Exists(real_file))
File.Copy(HttpContext.Current.Server.MapPath("~/App_Data/blank.mdf"), real_file);