My entire group is new to ASP.Net Core and I was the lucky one tasked with Authentication/Authorization. We have always used a DB first approach, and this is no different, we already have our DB all set up. The higher ups want to use our specific tables for all things Identity, but they also want to leverage the tools that ASP.Net Core gives.
This will be a multi-site app where there is one central database. Our current setup is close to what the scaffolding adds, but has some small differences.
I have read a ton of resources, but the vast majority all focus on the code first approach and I currently don't fully understand what I need and what is there for the code first approach. I have seen a couple of answers that recommend using the .ToTable and .Property inside of OnModelCreate. Is this the best option or am I better off creating my own stores and methods? I currently have a user model created and a store to go with it (based on this site). Is it best for me to try to expand that all the way out (don't full understand how to have it pull in roles and claims).
This is what our DB Schema currently looks like.
At this point we are creating our Roles and Claims via a db script. The only thing we will be using UI's for right now is a page that will let a site admin add users, and assign them roles, and any singular claims they need.
Any help or input would be greatly appreciated as I try to wrap my head around all of this. If I have left out any pertinent information please let me know. As I said with what I have now I can create a user and login, I just have no idea where to go from here (how to add roles and claims).
Here's how I think about it and the steps I would take to approach in solving this problem.
So Microsoft's implementation of Identity is an abstraction of the problem.
The Models that they provide and the Tables that are derived from them is their choice for the default implementation of the abstraction.
So essentially what you want to do is to plug in your models in to this abstraction.
To quickly generate these models from your database you might want to use scaffolding this will generate the DbContext and the Models, you will then have to configure the dbcontext to plug in your design.
And if you look at how you can create your own Identity Tables providing your own objects
here this can give you an idea of how to plug in your models/functions in to this abstraction.
You will most likely have to override the OnModelCreating method to configure the relationship of your tables.
Related
I'm trying to build an Inventory web application with .NET Core. In this app, I want to keep track of every create and update operation, so almost every model in my application has CreatedBy and ModifiedBy fields and each of those fields have a one-to-many relationship with the UserId field from the Users model.
So there are a lot of foreign keys in my models and lots of navigational properties in my Users model. It works but looks kind of messy especially in my Users model so it got me thinking maybe there is something wrong with my approach. I thought of some other ways but I am just learning the ropes so I can't really predict the possible downsides of those approaches, thus, I need help.
So what's the best way to deal with this kind of situation in a web application?
Should I keep defining foreign keys?
Should I store UserId as string in those columns?
Should I create another table which holds records for every create / update operation?
Is there a better way out there?
After some research I decided to go on with temporal tables solution from SQL Server directly. You have to add just a couple of codes to your dbcontext's onmodelcreating method to set it up and it looks like it's working very good for my needs.
Hi I'm trying to implement a class dbHelper to create a connection to an existing database on the phpmyadmin site.
I want to read and edit entries in the database. So my question is, how you would recommend to implement this in vaadin.
You're looking to create an application that supports create, read, update and delete (an acronym CRUD), which are the four basic functions of persistent storage.
Tutorials for creating CRUD applications with Vaadin has been done quite a few times. The article Creating CRUD UI with Vaadin as well as Spring Data JPA CRUD with Vaadin git repository provide a good step-by-step instructional. As #Andre recommended, using JPAContainers and Bean Item Containers are going to cut down the amount of code you need to write, so it would be worth your time planning your data models accordingly. If you have any specific questions on accessing data with JPA, or anything else please let me know!
I am wondering what jhipster entities are exactly?
What if I just want to create a new page/view without any database entry and relationship? For example: the about page, do I have to use the entity generator in order to create it? What are the benefits of it?
jhipster entity tutorial
Regards
redyar
Entities are typically objects that are backed by a database table. With JHipster, you can generate entities (and their associated screens) using Yeoman.
For an about page, or any other page, you can author them by hand. You don't need to use a generator. JHipster merely provides its entity sub-generator as a convenience for you.
You can also use the Yeoman generator for AngularJS to generate basic scaffolding.
http://yeoman.io
Immagine to build a website of e-commerce. That website contains users, sensible data informations, details about sellers and other things. You can save a lot of time creating it with Jhipster because it automatically create Objects class that represents database's tables, RESTful web services to manage them and the frontend view with Angular, CSS and HTML (all generated automatically). The objects that represent database's tables are entities.
With entities you can do CRUD queries on database using Java objects and Java methods with Spring framework. You can do queries by calling java methods. Thats all! After some practice it's really easy to use.
With that generator you don't have to configure relationships, constraints or things like that. Jhipster does that for you!
If you need a web application that does not use a database you don't need to use a generator like this, in my opinion.
I took the right Matt Raible's answer trying to give you more informations about entities. I hope to be helpful!
Have a nice day!
This may be an odd question! But I was wondering if anyone has ever attempted this. I guess the first question most people would ask is why!!
With index server you can add additional meta data to standard file information (name, size etc).
I want to be able to expose this information through to a BL component via nhibernate I need to write - so that when I replace the indexing, I don't have to rewrite the Business logic.
In theory, you would extract interface for indexing provider and then create a wrapper and wrap Micorosoft Index Server. Then when you have different provider, you create a wrapper for the new one and use IoC to inject implementation. I fail to see how NHibernate fits into this.
I'm a lead developer on a project which is building web applications for my companies SaaS offering. We are currently using LDAP to store user data such as IDs, passwords, contanct details, preferences and other user specific data.
One of the applications we are building is a reporting service that will both collect and present management information to our end users. Obviously this service will require a RDBMS but it will also need to access user data stored in LDAP.
As I see it we have a two basic implementation options:
Duplicate user data in both LDAP and the RDBMS.
Have the reporting service access LDAP whenever it needs user data.
Although duplicating data (and implementing the mechanisms to make this happen) as suggested in option 1 seems the wrong way to go, my gut feeling is that option 2 would not perform well enough (how do you 'join' LDAP data to RDBMS data as efficiently as a pure RDBMS implementation?).
I did find a related question but I'm still unsure which approach to take. I'd be interested in seeing what people thought of either option or perhaps other options.
Why would you feel that duplicating data would be the wrong way to go? Reporting tools (web based and otherwise) are mostly built around RDBMS's, so any mix'n'match will introduce unnecessary complexities. Reports are likely to need to be changed fairly frequently (from experience), so you want them to be as simple as possible. The data you store about users is unlikely to change its format very often, so once you have your import function working, you won't need to touch it again.
The only obstacle I can see is latency: how do you ensure that your RDBMS copy is up to date? You might need to ensure that your updating code writes to both destinations. Personally, also, I wouldn't necessarily use LDAP for application specific personal preferences: LDAP can't handle transactions, so what happens when data is updated from several directions? (Transactionality is of course also a problem with letting updaters write to both stores...) I'd rather let the RDBMS be the master for most data, and let LDAP worry only about identity, credentials and entitlements, which are rarely changed and only for one set of purposes. For myself, LDAP's ability to deal with hierarchical data isn't all that great a selling point.
Data duplication is not always a bad thing, especially when the usage scenarios are different enough.