We have a SL application and many users who use this system with different data and access roles. For example, each user can have some devices and each device will send its locations every 5 minutes to server.
One approach is defining a User table in database and have many tables which connect an entity to a user Id, but this is not a good idea as that creates many tables between users and other entities.
It will be a time consuming process to select user data or reporting, so I wanted to know what the best way is for handling such behavior in Silverlight?
You can use AuthenticationDomainService. This is a popular service for authorization users with roles. You can get more information there: http://msdn.microsoft.com/en-us/library/ee707361(v=VS.91).aspx
Related
We are a using a micro-service based pattern for our project where we have Users and their Orders. Users personal information (name, email, mobile) is stored in User table in relational database while we are storing Orders data of users in Orders collection in NoSql database. We want to develop an API to get a paginated list of all the orders placed with order details along with finer details of user associated like - user name, mobile, email along with each order. We are storing userId in Orders collection.
The problem is how do we get User details for each order in this list since both the resources are in different databases. We also thought of storing user name, email and mobile in Orders collection only but what if a user updates their profile, the Orders collection will have stale user data.
What is the best approach to address this issue?
You can use API gateway pattern, UI will call to API gateway endpoint and the Endpoint will call the both the API/services to get the result and aggregate it then returns aggregated response to the UI (caller)
https://microservices.io/patterns/apigateway.html
Well it mostly depends on scalability needs in terms of data size and number of requests. You may go with the API gateway if you don't have too much data and you don't get many requests to that service.
Otherwise if you really need something scalable then you should implement your own thought with an event based communication.
I already provided an answer for a similar situation you can take a look
https://stackoverflow.com/a/63957775/3719412
You have two services Orders and Users. You are requesting Orders service to get all Orders. It will return a response data which will contains ID of Users (each Order contains ID of User). Then, you will make a request to a Users service to get an information regarding User by ID which you got before. And finally, you can aggregate those results (if it is needed).
As guys mention, good solution will be to implement API Gateway here. As a client, you will send a request to a single port with endpoint (to a Gateway) and Gateway should create logic which I have described before.
I am designing a Node + MySQL backend for a service that requires two-factor authentication to be set up for all users as a part of the sign-up process. Users first submit a primary phone number and password (with the phone number being used for sign-in), upon which the server sends them an SMS with a six-digit code. Only after they enter the code is their account fully created.
This poses the problem of how to store data for users in the intermediate state after entering username/password but before verifying the code. Such "pending users" will not be shown in searches, do not need to store all the data a regular user would, and will be deleted after a few days if never verified. Furthermore, since every user must enable TFA to fully sign up, there will be orders of magnitude more users than "pending users". Thus, it does not seem sensible to me to have all users simply store an "isVerified" flag. I am familiar with SQL on a technical level but have no experience designing databases for production, and I am wondering what alternate mechanisms I should consider to solve the aforementioned.
My current idea is to have a separate table of pending users, having only those columns necessary to store intermediate signup information. When a user verifies, a row is created in the real user table, the signup information is copied over, and the corresponding is row deleted from the pending users table. However, this makes it somewhat ugly to ensure that the primary phone numbers are unique across both tables (which is an additional requirement of the service).
What methods/techniques should I consider to improve my solution?
You can store this data same way as store session information on server.
We now have one site running but we will need to build a branded site for our client soon. The client site will have exactly the same data set as our current site expect for the user data. The client site must have totally separated user info which allows only the client to use the site.
I don't see the need for setting up a new database or creating a new user table for the client. My tentative solution is add a "Company" column for the user table so that I can differ which site the user data row is on.
I do not know if this approach will work or not or if it is the best practice. Could anyone with experience like this shed some light on this question?
Thanks,
Nigong
P.S. I use LAMP with AWS.
Using an extra column to store a company / entity id is a common approach for multitenant system. In general you will want to abstract the part that that verifies you can only retrieve data you're allowed to a piece that all queries go through, like your ORM. This will prevent people new to the project from exposing/using data that shouldn't be exposed/used.
What's the best practice or the common way of keeping (or not keeping) Evernote users in your application's database?
Should I create my own membership system and create a connection to Evernote accounts?
Should I store Evernote user data (or only part of it) in my own app and let the user log in only with Evernote?
Summary: you must protect their data but how you protect it is up to you. Use the integer edam_userId to identify data.
I think the API License agreement covers protection in the terms:
you agree that when using the API you will not, directly or indirectly, take or enable another to take any of the following actions:...
1.8.4 circumvent or modify any Keys or other security mechanism employed by Evernote or the API;
If you cache people's data and your server-based app lacks security to prevent people looking at other's data, then I think you're pretty clearly violating that clause. I think it's quite elegantly written!
Couple that with the responsibility clause 1.2
You are fully responsible for all activities that occur using your Keys, regardless of whether such activities are undertaken by you or a third party.
So if you don't protect someone's cached data and another user is able to get at it, you're explicitly liable.
Having cleared up the question of your obligations to (as you'd expect) protect people's data, the question is how do you store it?
Clause 4.3 covers identifiers pretty directly although it's a bit out of date now that we are all forced to use oAuth - there are no passwords ever entered into anything other a web view. However, mobile or desktop client apps must provide a mechanism for the user to log out, which must completely remove the username and password from your application and its persistent storage.
For a web app, you can't even save the username: If your Application runs as an Internet service on a multi-user server, you must not ask for, view, store or cache the sign-in name or password of Evernote user accounts.
The good news is that you can rely on the edam_userId value which comes back to you in the oAuth token credentials response, as discussed here.
When you look at the Data Model, you can see the unique id under the User and going into the User struct, see the reassuring definition The unique numeric identifier for the account, which will not change for the lifetime of the account.
Thinking about the consequences, as you can't get the user id until you have logged into the service, if you want to provide a local login for people you will have to link your local credentials to the user id. That may irk some people if they have to enter a username twice but can't be helped.
You can allow users to log-in via OAuth. Here's a guide on how that process works.
But you'll probably also want to store a minimal amount of user data, at least a unique identifier, in your database so you can do things like create relationships between the user and their notebooks and tags. Refer to the Evernote data model for those relationships. If you're using rails, this will also help you take advantage of rails conventions.
I'm building four websites. They all should have the same login-datas (user can registrate on website 1 and also can use website 2 and 3 by using the same Login-Name).
My idea was to use the MS SQL Membershipprovider (good idea?).
Now I don't know where to place the SQL-Mebershipprovider (in an extra databse? or together with the websites? -> sound like getting chaos^^)
A other idea I've read was to create a webservice to the authentification?
But I think I'm getting problems with the data consitency, because I think there is no way to point from one database to an other (linking for example the usertable in database one to the texttable in databse 2).
I want to use MVC3 and a MS SQL-database.
Any experiences or ideas?
Thanks a lot!
You can use a separate membership database to do this and just point the providers of each site at this database.
If you wanted to use the role provider you would have to have the same roles in all four websites which may not be what you want. You could use a central database to just handle authentication and then create a local user record in each website that links back to your central user database (you will have to do this linking manually i.e. no relationship). This will then let you role your own role provider for each site.