Are there any advantages to using the Secret Manager instead of environment variables for developing ASP.NET Core, Azure Functions, Azure WebJobs and Xamarin projects using Visual Studio 2017?
Maybe another way of asking the same question but which one is the newer/more preferred method?
Secret Management is a mechanism of storing sensitive arguments within the profile of executing user, while using environment-variables aren't hidden from the view. Aside from the location of such data, I don't think there are any other major differences related to performance of retrieval or similar. You won't make a mistake if you decide to store non-sensitive data using the same secret-management, if you'd like - at that point it becomes a preference.
Related
Back in 2008 I remember running into a 3rd party tool that did 99.9% of the work of implementing task/role security. From what I recall it was simply an extension of what was built into .Net. You ran a script to add all the needed tables to your SQL Server then used the UI to go in and define all the tasks and then grouped the tasks into roles. The assigned users to a role. The power was that different roles could have the same task and it was all configured by the UI tool that came with this system. I also thought it was on CodePlex, but I don't recall the name. All I recall it was Microsoft's name with like Sql or something added to the name of it.
At the time, 2008 (VS2008 days), I was told by co-workers that Microsoft was slowing consuming the whole system into .net.
Anyone have any idea what the name of the thing was I am thinking of? Is it part of Microsoft .Net now?
Are you perhaps thinking of NetSqlAzMan, which uses a similar authorization model to Microsoft AzMan? Or perhaps you're thinking of AzMan itself, which has a UI and allows storage in SQL Server?
I am looking for a way to have ColdFusion and ASP.NET share session variables. I have seen posts in the past saying that you cannot do this directly with out calling some sort of ColdFusion function to return some sort of string representation of the session. I have recently learned about something called ehcache that is a third party session storage tool. That got me wondering is there a third party session tool that will allow ASP.NET and ColdFusion to share a session.
Some details about our systems:
They are running Windows Server 2008
We are using IIS
We are using ColdFusion 9
ColdFusion/Railo and asp.net can use EHCache, but they're very unlikely to share sessions out of the box. Each will have their own session key, which they'll use to put the data in/out. They'll all have their own way of storing the data. I may be wrong, but from memory, ColdFusion uses WDDX, Railo uses something like JSON and I've no idea what the .Net platform uses.
The point is that each hides the complexity of dealing directly with ehcache, but they each do it in their own way. If you want to interoperate, you may need to have each read/write directly to ehcache (or the database). You'll also have to work out a way of sharing a common key between .Net and ColdFusion.
If you're rolling your own version of this, then using JSON proably makes sense as the common format.
Environment:
ASP.Net 4.0
MVC 4
SQL Server 2005
Visual Studio 2010
Issue:
We have an SQL 2005 Database which is transactionally replicated to a separate server because a number of large business queries are run against the data and slow the system down. The secondary server is used for all reports (read only), while the primary server is used for day-to-day business. Our legacy code uses stored procedures to access the database and it was relatively easy to maintain different connection strings and have all reports use the report server connection string. We've recently started writing all of our newer code using Entity Framework for data access, however, and I'm at a loss for how to deal with the two different servers.
A simple solution would be, perhaps, to simply maintain two .edmx and point all of the reports to the second .edmx. I strongly dislike this method, however, as it requires that the developers maintain the two different files.
Has anyone else encountered this scenario and devised a more appropriate solution? Is there any way I can use the same .edmx for both servers (since they are identical) but somehow specify at the Controller or Action level which connection string to use?
Ideally I am looking for a solution that does not require manual SSDL writing. I'd like to continue to use the designer and "Update Model from Database" features.
Thank you for your time,
Mirzero
When creating the EntityContext object you can specify a connection string in the constructor. So you would just need to pass the required string to the method creating the EntityContext instance.
I'm considering using an object oriented database in Visual Studio .NET for my web application, which is basically a web store.
Which should I consider, Eloquera or db4o? Can I have some fresh perspective?
A similar question was asked like 10 months ago - please also mention changes since then.
The features that I consider important are:
Ease of integration into web application project.
Ease of querying using LINQ.
Ease of deployment upon release in IIS server.
Multi user support.
Looks like db4o could be a fit for your needs, but that depends on two factors:
If you're going to host your web store on a hosting provider db4o won't work in a limited trust environment
Depending on the number of simultaneous users, db4o could be a fit or not. As a rule of thumb I would say that if you're talking about more than 50 users hitting the db at the same time, then you should look at other options (one example: Versant Object Database).
Disclosure: I work for Versant and db4o.
Another option would be RavenDb -- it is more of a document database than an object database but it satisfies your requirements by and large:
Easy Integration: insanely easy; use nuget
Easy Linq: linq is the query platform
Easy for IIS: pretty much set up an application pointed there and you are done
Multi-User: yup.
I suggest Eloquera. All the pros of db4o (and more), less some cons...
Real World Experience of db4o and/or Eloquera Database
Eloquera is multihreaded, in opposite to db4o. So, if you expect more that a single visitor to your website, Eloquera is an obvious winner here.
Moreover, Eloquera provides the object-oriented and document-oriented APIs, which can be used together.
I just discovered ASP.net uses its own profile system to register users and there seems to be a lot of features available as bonus with it (such as secure authentication). However it seems rather specific to have such a feature for a general purpose development environment and things which work in the background the way the profiles system does without me really knowing how (like where the user data is stored) kind of scares me.
Is it worth developing a website which requires user authentication using the asp.net profile system or would it be better to develop my own using SQL databases and such? I'm not going to avoid using SQL anyway, even if I use profiles I'll use the profiles unique ID to identify user data in the SQL table so in that sense I'm not going to avoid using SQL for user information at all.
My favorite thing about profiles is that you can create custom permissions in Web.config files using them () and avoid having to type in the same code to the top of all your aspx source files to do the authentication check.
The other thing I kind of like about it is that security is built in with secure authentication cookies, so I wouldn't have to deal with them myself.
But it doesn't seem like that big of a deal really. I'm just confused as to where profiles stand as far as ASP.Net development goes and what they're designed to accomplish.
The Profile/Membership and Role provider API is very intertwined, and specifies things very narrowly. The benefit is that there is little you have to do to get a lot of functionality working. The disadvantage is when what you need doesn't match what is provided. Nevertheless, there are many potential gotcha's that the API takes care of for you that it really does make sense to use it, at least for authentication.
My needs did not match what the API provided, and I really only needed the Membership portion. The problem is that I had a piece where I needed to use the same authentication and authorization across a web application and a desktop application. My needs are pretty unique, but it's designed for a classroom setting.
Getting the membership to work for my needs wasn't that difficult. I just had to implement the Membership API. There are several features I just didn't need with the Membership API like self-registration, etc. Of course this did present me with a challenge for role management. Typically, as long as your user object implements IPrinciple it can be used directly--but there are serialization issues with the development web server Visual Studio packages if your user class is not defined in the same assembly. Those problems deal with serialization, and your choices include putting the object in the GAC or handle cross-appdomain serialization yourself with objects that are in the GAC like GenericPrincipal and GenericIdentity. That latter option is what I had to do.
Bottom line is that if you don't mind letting the API do all the management for you, than it will work just fine. It is a bit of smart engineering work, and attempts to force you down a route with decent security practices. I've worked with a number of different authentication/authorization APIs (most were not CLR based), and the API does feel a bit constraining. However, if you want to avoid pitfalls with session/state/cache management you really need to use the API and plug in your own providers as necessary.
With your database, if you need to link a user with any database element you'll be storing the user's login id (Context.User.Identity.Name).
You seem to mix the Profile/Membership/Role provider API. But to answer your question: why not use it? I would use it unless there is a real constraint that makes it unusable...