we have a live azure mobile service using dot net backend. The apps using it are out & people are using them.
If we add a few more nullable fields to one of the classes in azure service, will the existing client apps keep working, without an update?
Or do all users must require to update the app before continue using the services?
Existing clients will keep working. On the client side, when it receives objects with properties which it doesn't understand the serializer will just ignore those. On the server side, when it receives the data from old clients, any properties which you have added to the class will have its default value (e.g., if you have a new integer property, it will have the value 0, and for string properties the value null). As long as the logic in the service controller can handle those default values, then your application will be fine.
If you are using entity framework.Base on my test, it's OK.You don't have to change your client-side data model.
P.S. If you just change your entity class.It may clear your database.Be careful with that.
If you want Entity Framework to alter your database
automatically whenever you change your model schema, please use data migrations.
For more information refer to the documentation:
http://msdn.microsoft.com/en-us/data/jj591621.aspx
Related
I am working on an application where I need to setup identity server 4. I have an api as resource. and a web forms application as client.I have few roles like teachers, students, parents in my database. How can I use this custom database and perform authentication and authorization without using identity?
Please suggest.
From your other question here I get a better idea of what you want.
I think one solution for what you want would be to setup identityserver4 in a seperate project with its own seperate database. I noticed the tag identityserver3, but I think it is quite safe to go for identityserver4. It shouldn't make a difference for the client/user since they are conceptually compatible.
1) Give your application a client/secret (which you configure in identityserver) in order to identify your application and grant access to the resource api. Here is some information: http://docs.identityserver.io/en/dev/quickstarts/1_client_credentials.html
You'll only need to configure one client to protect your resource from the outside. The only way to access the resource api is through your application, since your application is making the actual calls. This is also the drawback, you cannot expose the token to the outside world.
Since your client isn't the actual user, you'll need to identify the user. You can use any mechanism based on your current model as you like. A simple user/pass (with or without asp.net identity) could be enough to determine the roles. But please keep in mind that your application has full access to the resource api.
2) However, since identityserver is available, why not use it? Why don't you want to use the identitymodel? I think you should consider to seperate the identity information and your datamodel. Your datamodel shouldn't be aware of the security. And the security has nothing to do with your datamodel.
When you create a seperate database for identityserver you have one place to configure the identity users. All you need is a reference (sub) to the user in the datamodel. http://docs.identityserver.io/en/dev/quickstarts/2_resource_owner_passwords.html
Add claims or roles and everything is in place and you'll see there is no need to keep identity data in your custom database. The structure of your custom database stays intact, including the user table but without the identity data.
I think this is a safer solution and considering the good documentation and sample projects it may even turn out to be a quicker solution.
I'd like to create a Azure Mobile Service (.NET) that reads / writes from an existing database that is being used by an MVC 5 app. I've been trying, without luck, for the better part of a day to make this happen through the few examples that exist on the internet.
I've just now come across this SO post where Carlos Figueira says that a mobile service creates a new schema with the same name as the service name and all access is done via that schema and the user that has permission to that schema. If this is the case, how will I be able to have my mobile service connect to an existing table, if it always creates new tables in the new schema?
Also, I'm getting the impression that mobile services using .NET is much happier if I don't attempt to connect to an existing DB. Is this the case?
Azure Mobile Services will only work with tables in the new schema (with the service name). In order to work with an existing database, you need to transfer the tables to this schema, and then you will need to rename all your PK columns to "id" (lowercase). Once you have done that, the tables still don't show up in the Data tab in the management interface, but you can 'add' them and then it will connect and you can work with your existing data.
See this link for full walkthrough: http://www.strathweb.com/2012/12/using-existing-database-with-azure-mobile-services/
I'm starting a new project and I want to use AngularJS as Frontend and SailsJS as Backend. I have a requirement to separate databases for different clients. So, each client must have its own database.
I didn't find how to make this in Sails and Waterline. Does anybody know how to do this?
I have to change schema(or database) in runtime.
Right now, Sails does not have support for multi tenant databases.
It all depends also how many customers you have.
One approach that you can do (as with any other framework/language) is having (at least) one instance of your application pointing to different database configurations. Then have different domains for each customer. This involves creating a new "domain" per customer.
Another approach (that involves more coding) is to have the concept of an Organization entity that owns every object and include that on every filter.
There has been some PRs in the past about it but didn't move forward.
My client has a database (TS) for a project I'm working on. This database has a Stored Procedure called Logon. Within that SPROC is a call to a second database (RRA), which is their custom authentication DB that is used across all of their projects. The result of this call is the Role(s) a user is assigned to (assuming authentication passes, of course).
I'm attempting to do this via WCF RIA Services. When I create my ADO.NET Entity Data Model, I'm not sure which Data connection I should use - the one that connects to TS, or the one that connects to RRA. I'm going on the assumption that its TS.
Beyond that assumption, I'm still stuck. I know I can add an Import Function to that Logon SPROC. Where do I go from here?
I agree that you should target the TS database.
Here's a walkthrough of using stored procs.
http://www.robbagby.com/entity-framework/entity-framework-modeling-select-stored-procedures/
And here's an answer to how you can create a custom authentication using RIA Services.
RIA Services: How can I create custom authentication?
I'm currently migrating my sqllite application to using core data. When I created the data model I noticed that an attribute can be marked as and Identity property. Happily I marked that attribute as required and indexable only to find out that I have to supply the value myself or the insert of the entity fails, which kind of takes away from the idea of the data store providing the identity for me.
So if the identity property doesn't work like I thought it does, does anyone as any idea what its for?
Digging in the documentation and on this site it became clear that core-data as it's own identity object. Is this what I'm suppose to use? Is this how relations are created between entities?
The attribute which marks a property as an identity property in the modeling tool is in the Sync Services pane and is only used by Sync Services, not Core Data itself.
You aren't supposed to worry about CoreData's internal identity but rather manage your relationships by creating the proper relationship associations in the CoreData designer and associating actual objects rather than ids.