I am writting a Silverlight Business Application with WCF RIA link.
I have 2 databases on same SQL server, Public and Private.
The Public database contains a table which is mostly for public access level, like "user" table which has basic user information
The Private database contains a table which has "private" information, user bank transactions etc
I created 2 ADO.Net entity models, one each for Private and Public database and selected the tables.
I also created 2 different domain context services
On on Silverlight page, I need to get information from the tables that are across 2 databases, Private and Public as described above.
How do I achieve this? I am thinking of some kind of a wrapper that internally gets data from domain services.
Whats the best approach?
You can simply just create two, or more domain services classes in your web application and (rebuild) they will be available in the Silverlight application.
There are a few restrictions, you can't have the same table in two different domain services classes. You can't use two domain services from two separate web applications the domain services must exist in the same web application which you chose for the WCF RIA link.
Hope this helps.
Rich
Related
I am trying to design a simple microservice application. In a large application where application screens are shown to user based on roles.
Is it a good idea to design a separate user database and create user service to authenticate users.
System Details:
Lets say I have 2 microservices designed in .net core 3.1
Product Service and Orders Service.
Authentication of requests will be managed by API gateway-Ocelot service. User service will be generating token and passing it on to front end who will call my gateway- ocelot which will call Product and Orders service.
I am just focusing on user database for this question scope. Below is what i found so far
Force users to use Azure AD. This way you don't have to manage a separate database
Have user table in both Product and Orders database. This way authorization based on roles will be convenient but here you will be violating microservices concept and duplicating user code.
Summary of my problem
My project is more complex but here is my problem at very basic level. I have a Blazor WebAssembly project where I do just basic CRUD operations.
I also have a small database and lets say I have two tables Users and Roles. What I do is to create their classes in Database-First fashion, by using Scaffold-DbContext and I run this command on the Shared project because I also want to reach to these classes from both Server and Client projects.
When I try to used Individual User Accounts on Authentication tab when creating a Blazor WebAssembly project, it creates the data models in the server. Which means I cannot access to my tables from Client Project. They need to be in Shared. Also it is Code-First based. I don't want to use migrations.
What I tried
What I tried to do is to create an identical -almost- project with Individual User Accounts projects but my Users class inherits IdentityUser and my DbContext inherits ApiAuthorizationDbContext but problem starts here.
I cannot add ApiAuthorization package from NuGet because it says Shared project does not compatible with .NetStandard 2.1.
Also changing Shared project's standard didn't work.
Some Questions
Can't I just add my users table on the Shared and use Identity from that table? (Since it's just a single table of rather larger database)
Do I need two databases for this? One for Identity, one for rest of the application?
Do I need to use Identity for Authentication & Authorization? What else can I use? Or Can I use a custom one where I can use it as I described earlier (Having models in Shared project)
My Goal
I want to authorize users with [Authorize] property. Since I cannot accomplish the registration, I cannot proceed.
Use 2 DbContexts. The Identity tables (yours or ASP.NET) should not be part of the Shared or Client projects.
I want to authorize users with [Authorize] property
The real authorization happens on the server, nothing in the client is safe. Have you looked at the complete (JWT based) implementation in the template?
Can't I just add my users table on the Shared and use Identity from that table? (Since it's just a single table of rather larger database)
No, Identity needs the base class. And your client app doesn't need (and shouldn't see) most of its properties.
Do I need two databases for this? One for Identity, one for rest of the application?
That is the best way. Note that you can have 2 DbContexts for 1 physical Db.
Link to the User wit a simple UserId (no Nav property) when needed.
Description:
I was facing some design issues with the authorization mechanism in my ASP .NET Framework WebAPI 2 project. The application which I am working on majorly has 3 parts
Controllers - Endpoints
Services - Where shared business logic is written
DAL - DB calls are written
It is always a practice to get the user id (any user identification properties) from the authentication mechanism (here JWT claims).
Problem Statement
Where should the code for getting the user id to be written? Should it be written in the Controllers and then passed down to the Service layer or should it be accessed in the Service levels directly?
Thanks in advance.
I'm creating a mobile app for user with an analytics dashboard for business. I currently have two APIs:
The main API, to manage user resources.
The business API to query analytics about the users resources.
My problem is that I'm trying to create a single Authentification API. I want the login logic to be independent from other two API's. The flow that I see is:
User or business log in -> LOGIN API -> Generate Token with claim of AccountType.
I'd like to also have three separate DbContext with the two others linked to CredentialsDBContext
public class User {
public Credentials Credentials {get; set;} // CredentialsDBContext
public Shirts Shirts {get; set;} // MainDbContext
}
How can I do this, knowing that you can't create have two DBContext in a single class?
happily you are not the first one who wants to this! actually this is the approach most of the server-side apps take.
There is a protocol called OAuth2.0 with OpenId Connect which help you to completely separate user authentication/authorization from your business logic.
There are popular libraries that do this job for you like :
IdentityServer4
OpenIddict
and much more
Also it worth to note that you can have multiple DbContexts in your project and they can also point to the same database, but that way it may be hard to create the database using Code First approach and you may need to create it manually.
I've seen various attempts to place two or more web sites (URLs) on an Azure Cloud Service Web Role. The solution is basically to hack up the ServiceDefinitions.csdef file which is a bit of overkill and doesn't appear to be supported by Visual Studio (VS forces you to have a dummy 'master' role and your web sites are manually patched into the configuration file. This is a big red flag that the architecture of multiple websites in a single role isn't anticipated by Azure.)
Instead of hacking the config file, is it possible to create multiple endpoints and associate them with interfaces, such as with WCF? As I mentioned in my original question, I have three ways I want the users to connect into an Azure 'Role': one for the data model (CRUD operations), one for the operator console (start, stop, statistics, etc.), one for the user-defined functions (the web site should be extensible). I would like a separate endpoint for each of these major function groups (that is, well defined interfaces). It's trivial to do in WCF but I don't see how it's done in Azure.
Web Roles support up to 25 input endpoints per deployment, allowing you to host multiple services in the same role (independent of instance count), just by setting up your service to listen on a specific named endpoint which you create ahead of time (it's part of the service definition).
As you scale out to multiple instances, the input endpoints will likewise be load-balanced across your role instances.