I have a few MVC4 websites that share some of the same images / videos / pdfs etc. They are confidential: that is only authorized users can access them.
At the moment I just have the content in a folder under one of the web apps, and then I create a symlink to that folder from within the other web apps so that they share that directory. I don't want to do this because it makes things complicated for testing and deployment and would rather have some kind of CDN type of website to serve it.
What's the best practice here?
I guess you've answered your own question. Try using a CDN instead of having them inside your server(s) and shared across your other web apps. Some CDN's may or may not have authentication.
One CDN you might want to consider:
Amazon S3 (it has token auth)
Another is Softlayer (this also has auth)
If you really intend to create a CDN-like website, I would say, do a cost-benefit analysis. Is it worth to build it from scratch? Can you just get a CDN (with authentication, of course) and host it by yourself? Or can you just have it hosted externally (which might be more reliable as well)?
Just my 2 cents.
Related
I've to develop a WPF application in an intranet environment with no internet access for security reason. I was wondering if it's possible to collect data locally (on a server) then to FTP them or even better to have the application insight alternative installed on a Server.
Has anyone faced a similar situation and have been able to solve it?
You could do something like that yourself if you really needed to. Instead of using the built in InMemoryChannel or ServerChannel classes to send telemetry, you'd create your own implementation to store them somewhere else. (or you could change the endpoint that the default channels point to to a web service inside the intranet.
you could then collect those files up and ftp them outside, and write another service to read those files and send the telemetry to app insights. Though it seems less like a good idea given the intranet with no internet for security reasons.
Or, better yet, you could simply write internal service to parse and store all that telemetry and show it on that web service inside the intranet and use appinsights only as an sdk and schema, and don't send any of your data outside your intranet at all.
More likely: upvote adding AI to azure stack, (https://feedback.azure.com/forums/357324-application-insights/suggestions/11683746-bring-application-insights-to-azure-stack) and then get an azure stack implementation inside your intranet? then you get all the other goodies of Azure from Azure stack as well.
Q1: Where do you think is the right place to put a SQLite database file (database.sqlite) in Azure Web App file system? For example:
D:\home\data\database.sqlite
D:\home\site\database.sqlite
D:\home\site\wwwroot\database.sqlite
other?
Q2: What else should be taken into consideration in order to make sure that the database file won't be accessible to public users as well as not being accidentally overwritten during deployments or when the app is scaled up/down? (The Web App is configured for deployments from a Local Git Repository)
Q3: Where to learn more about the file system used in Azure App Service, the official source URL? E.g. how it's shared between multiple VMs within a single Web App, how does it work when the App is scaled up/down, what's the difference between D:\home (persistent) vs D:\local (non-persistent)...
Note that SQLite does not work in Azure Blob Storage, so that one is not an option. Please, don't suggest alternative storage solutions, this question is specifically about SQLite.
References
Appropriate Uses For SQLite
In a Web App, your app is deployed to d:\home\site\wwwroot. This is the area where you may write files. As an example, the ghost deployment writes its SQLite database to d:\home\site\wwwroot\content\data\ghost.db. (easy to see this, if you open up the kudu console via yourapp.scm.azurewebsites.net):
This file area is shared amongst your web app instances. Similar to an SMB file share, but specific to web apps (and different than Azure's File Service).
The content under wwwroot is durable, unless you delete your app service. Scaling up/down impacts the amount of space available. (I have no idea what happens if you scale down and the smaller size has less disk space than what you're consuming already).
I would say the best location would be app_data folder in the site/wwwroot folder. Create the folder if it doesn't exist.
Web Apps can connect to storage accounts so you can in fact use blob storage and connect that to your web app. So in terms of learning more about it then you need to be looking at the appropriate page of documentation.
In your Web App settings you can then select which storage account to use. You can find this under Settings > Data Connections where you can select Storage from the drop down box.
I want to host 2 websites (Asp.net MVC) they have one folder with the same name and I want to copy data from one website to another periodically. For example website1/file/ to website2/file/.
That's why I thought to create a Windows service in order to do that.
My question is how can I copy data between these two folders via http.
Personally with the complexity around developing a solution I would look to use some kind of service like DropBox.
Another alternative would be to store the files in a distributed file system. This could be Amazon S3 or Azure Blob Store. This eliminates the need for the entire synchronization in the first place. This can be fronted by a proxy web service that can stream the file to the end user.
The reason I suggest this is because there is a lot of complexity around managing the synchronization of files via HTTP.
I don't think you will get a full solution on StackOverflow but I can make some recommendations.
I would use a master-slave system to co-ordinate synchronization. This would require some design and add to the complexity. But would give you the ability to add more nodes in the future. Implementing a master-slave system can't be easily detailed in a single post and would require you to research it further. There is good resource on here already. How to elect a master node among the nodes running in a cluster?
Calculating delta's for each node. e.g. What files do I have the master does not? What files does the master have that I do not. Are their naming conflicts on other nodes? How to determine what is the most upto date file?
Transfering the files.. Will require some sort of endpoint to connect to either as part of the service or as your existing website.
Http Client to send the files and handle progress/state of transfer for error handling.
Error handling over all, what happens if a file is part transfered to the Master and how to clean up failed files.
That is probably the tip of the complexity of trying to do this. Hence my recommendations of using an existing product or cloud service.
I am building a set of services based on MVC 4. They should all be a part of the same authentication system. Currently I have got a separate project for all the model handling, including the Forms Authentication you get by default when making a new MVC 4 app.
Now, I would like to make a toolbar for logging in to our cloud services, and this toolbar must be made in such a way that it can be imported into our other services. Logging in with this toolbar should log you in to all our services, that are separated into different MVC apps. Thus logging in when browsing "service1" and then going to "service2", you should still be logged in with the same user.
Can anyone point me in the right direction here? Should I make a separate MVC app for this toolbar, and somehow reference it in all of my other projects? Should I export my controllers into a separate project and use them? I am not sure what the best practice is here, nor where to find the info I need on the matter.
Since you will be hosting your applications on different domains, you could implement some Single Sign On mechanism the way SO does it over the Stack Exchange network: https://meta.stackexchange.com/questions/64260/how-does-sos-new-auto-login-feature-work/64274#64274
Different domains means that you won't be able to share the Forms cookie. You should rather learn how to use one of the enterprise Single Sign-on protocols - using a recognized protocol means that you can easily integrate other applications, even if they are developed in different technologies (standarized protocols are supported by most development environments).
Possible candidates are:
the OAuth2 protocol. It is a respected protocol as Google, LiveID, Facebook, Twitter and others support it. To build an OAuth2 server you will need a framework like the DotNetOpenAuth.
WS-Federation. Got a lot of attention in .NET world as we got the Windows Identity Foundation framework which lets you create WS-Federation servers and clients.
Anyway, my advice is to invest your time now as this will pay off well in future.
I am using sharepoint solely as a repository to store and retrieve large files (~100 MBs). How can I authenticate a web application such that it can upload and download files to a document list on Sharepoint 2007 without using Windows intergrated authentication?
The web application will handle the authorization - it'll figure out which users are allowed to access the repository via integrated windows authentication and a bunch of business rules that depend on the application's state. When the user wants a file they will use the web app. The web app will then download that file on the user's behalf using some sort of credentials. I prefer that these credentials be somewhat permanent so it's password doesn't expire every so often. I was thinking of using basic authentication because the files that I'm access controlling aren't high valued files (so its poor security is tolerable), and it seems to be the simplest. What are my options?
I wouldn't recommend using SharePoint for this at all. Its value comes from the features it provides through its user interface. If you remove this then you are looking at an expensive and over-complicated data store.
SharePoint stores all data in a database. Storage for databases is more expensive than storage for files. It's more costly to configure, administer, backup, load balance, scale, etc...
Development time is more costly with SharePoint. It's a big and complex product that's not trivial or quick to develop against. There needs to be a solid business case and using SharePoint for its back end only isn't a good one.
Please seriously consider this approach before going down it!
You are better off just enabling windows auth on your web application and then setting the permissions to the folders/files.
If you do need to get just the files however...go to www.codeplex.com and search for sharepoint powershell. There is a script there to upload stuff. This could be modified to download I believe.
As mentioned above, using SharePoint as a repository pretty much nullifies any of its benefits. You might as well just use a database to store your content (that's what SharePoint is doing behind the scenes anyway.)