I see several SaaS companies, such as bitrix have different top level domains by country ex:
bitrix.de for germany
bitrix.in for india etc.
A lot of times this is required because of legal requirements that the data generated in Germany should stay within the EU/German data center, and vice versa same for India.
My queries
To achieve the above, there would be 1 database + 1 App Server in India, and a similar 1 database + App server for Germany also?
What should happen if a user created an account on bitrix.in ie in the Indian database, and then he goes and tries to accidentally log in to bitrix.com, should such a login go through or should I tell the user that he is on the wrong site?
Tx
You can create a central database for storing meta data - accounts, logins, etc. This could be common/shared across all countries/domains or it could be separate in each database but replicated at a central meta database.
Now when someone logs in, after authentication (using the central meta database) you can redirect them to the appropriate domain.
In such a configuration when creating a new user you will have to ensure that the user is unique across all domains/databases.
Related
I freelance for many clients and handle development and web hosting myself. Many of my clients want professional business email so I usually set them up with G Suite (sometimes MS Office 365 Business).
Currently, I've made a new G Suite account per domain and added their employee users that way. (some have multiple related domains so I'll keep them all together in that one account).
It's becoming hard to manage all these logins though and I was thinking would it make more sense to add all of my freelance clients domains to my business's G Suite account and manage their users that way?
Example: I have my example.com domain and main user is me#example.com
Three of my clients have domain1.example, domain2.example and domain3.example with multiple users. Can I add all three of theses to my #example.com G Suite account and manage their userbase that way?
Or should I stick to separate G Suite accounts for each freelance client?
Here is a link detailing some of the limitations: support.google.com/a/answer/182081
I am working on system that will manage orders. Orders can be created via admin or via customer. Employee can take orders and change it's status.
My system should have three global types of users:
Admin - this type of users mostly uses WEB interface. Admins have different access levels, so some of them can only create orders, and others - edit core info about pricing and so on.
Customer - this type of users uses customer's mobile app. Main action is to add and cancel orders.
Employee - this type of users uses employee's mobile app. Employees can see open orders, assign themselves to orders and change order statuses.
Also, Customer and Employee can be authorised with phone number, that can be changed at some time (independently of each other). Admins can be authorised with uname + pword.
Current solution has one table for Admins, one for Customers and one for Employees.
So first part of question is how to structure database properly?
The second part is about authorising in REST api. In current solution I have three endpoints, that are authireses usertype independently.
admins/auth
customers/auth
employees/auth
And my thoughts is to keep three tables as is, because each usertype is slightly different concept and really independent. And keep authorisation as is, but add something like roles and privileges to auth token to restrict access for some resources.
I have two-step authentication on facebook. I just tried to log in from my home PC but didn't write second step code.
I've got notification that somebody (me) was trying to login to my account and location was so precise (within 2 meters).
I wondered how facebook detects location so precisely only based on IP?
Today geolocation is in the core business of Marketing companies, there's a very developped market of customer data, so tons of mobile apps and services collect data such as usual IP addresses, personal information, interests, locations.
That information gets reselled to data brokers, aggregated, corrected. And then Facebook or others can buy that data, merge it, implement corrections and so and get tables for matching IPs and locations that are not public, it seems.
However they offer a high level API to perform market targeting which seems to use that data:
https://developers.facebook.com/docs/marketing-api/buying-api/targeting#location
In your case it was precise because they may have a good dataset based on your privacy settings experience, not only with facebook but with other geo-located apps. In my case their guess is wrong by hundreds of Km, because I was behind a corporate proxy.
In Google Apps, there is always a base/primary organization. But Google Apps can have subdomains and suborganizations both (or combination of those).
We want to be able to identify the currently logged-in user as being part of the overall organization, whether it be the primary org/domain or some subdomain or suborg. But when you get user info or license info, it returns the home domain of the currently logged in user as the ID for their organization. No ID is consistent across all subdomains or suborgs.
I've also tried listing all orgs using the organization apis, but that doesn't seem to work when trying to get the org info of the root org: https://developers.google.com/admin-sdk/directory/v1/guides/manage-org-units
Is there a way, given a particular Google Apps user, to determine what the primary organization is?
The only alternative we have is to treat every domain/subdomain in the Google Apps org as it's own independent org. This is less than ideal because now a Google Apps admin who manages all of their sub-orgs/subdomains in one place in Google will now have to manage a separate organization in our app for each domain in their overall org. This uses up extra resources in our system for creating these additional orgs, but more importantly creates a very confusing organization/user management model.
When you look at the Users resource for the two users, compare the customerId attribute. If they match, the two users are in the same Google Apps account. If they don't they're not.
Also, don't assume two logged in users are in the same Apps account. One could be an Apps account and one could be a consumer account even though they have the same SMTP domain.
Is it possible to create/store user accounts in a data store that exhibits eventual consistency?
It seems impossible to manage account creation without a heap of architectural complexity to avoid situations where two account with the same UID (e.g. email address) can occur?
Do users of eventual consistency stores use a separate consistent DB as an identity store, or are there solutions/patterns that I should be exploring?
Thanks in advance,
Jamie
It is possible to do use management in an eventually consistent data store. We do it. It works under the following assumptions:
Conflicts shouldn't happen and when they do there's a clear path to conflict resolution. If the account ID is a person's email address, then if two separate people try to register under the same email there's a bigger problem here. What we do in this case is block both new accounts as soon as the conflict is discovered and send an email to the address in conflict explaining to the user that there's an issue (possible fraud). You can either ask the user to reset to the account or ask them to contact support.
Repeated access by the same user within the timeframe in which the data is inconsistent go to the same replica. For instance, if a person just registered and the next request is a login, you must validate that login against the data replica where the new registration details exist. So if the eventual consistency is due to multiple data centers in different geographic locations and under normal conditions a request goes to the closest data center geographically, you're OK.
There are some edge cases, such as if a user registered against one data center, then that center crashed, and now the user cannot login even though he still can see the application - served from some other data center. You can calculate the expected frequency of this case based on your number of daily new users and average data center downtime. Then decide whether it's worth worrying about one user in a (million/billion/whatever your number is) having a problem and possibly contacting support. I faced the same decision not long ago and decided that from a cost-benefit perspective the answer is no.