I'm developing a system that allows multiple offices to exchange their data.  As replication happens at the database level I'm assuming I will have to come up with a way to synchronise things like users and passwords?

= Steve

Steve


>I'm developing a system that allows multiple offices to exchange their data. As replication happens at the database level I'm assuming I will have to come up with a way to synchronise things like users and passwords?

That depends (I do like starting an answer like that)

Will all the people need to be able to log in to the system at every workstation?

Is access to the data dependent on who's logged in?

If its simply a matter of some of the columns are the user ID but its simply for information then it doesn't matter. As an example - in my recruitment app which I use every day we track calls made to people, emails sent etc. Part of that is the user ID (mine is RL strangely enough) so that anyone using the system can see if there's been a contact with an individual and if so who made it. If the system was operating on a replicated database the only reason for synchronising users and passwords would be so the system doesn't allow another RL. In my case there's a staff table which holds a lot more information than just the user ID (it doesn't hold the password that's only in ElevateDB) so I can do what I need.

A bit rambly but I hope it helps.

RL aka Roy Lambert

Steve

>>I'm assuming I will have to come up with a way
>>to synchronise things like users and passwords?

Only if users from Office "A" (where they are set up as Users) regularly travel to Office "B".

My own systems of replication tend to consist of a central server in the office, with individual laptops as the nodes (the "salesman model"), users with laptops always use their laptop even if they are in the office, so provided they can log into their own device everything is easy.

Replication has been quite cleverly defined in EDB in quite a clean but open way, which allows quite a wide range of implementations (1 central node, several central nodes with data-exchange, chaining of updates, use of replication as a form of Backup process ...).

This does also mean that you are in charge, and it won't automatically do exactly what you want.

I put a simple-but-working Replication test programme on the binaries forum a year ago, which you might like to play with (http://www.elevatesoft.com/forums?action=view&category=edb&id=edb_binaries&msg=81&page=1).

One of the biggest gotchas is what happens when your DB structure changes. Bear in mind replication only works between tables with the same structures, so structure changes must be done carefully to avoid losing integrity between nodes in a replicating system.

Once you get it working it is magic.

Roy and Adam,

Yes, users may move between offices and expect to be able to access their personal data in any office they visit. I'll have to work out a way to exchange information on new users, deleted users, renamed users, password changes, etc.

<< In my case there's a staff table which holds a lot more information than just the user ID (it doesn't hold the password that's only in ElevateDB) so I can do what I need. >>

Yeah, I do something similar with a UserData table.

<< One of the biggest gotchas is what happens when your DB structure changes. Bear in mind replication only works between tables with the same structures, so structure changes must be done carefully to avoid losing integrity between nodes in a replicating system. >>

Ahh, good point.  I'll have to work out a solution to make sure they all use the same database structure.

= Steve

Steve


Where are the user passwords held - if its in the config (I think its at that level not the catalog) then it will be more awkward. If they're held in UserData then its simpler.

Roy Lambert

Hi Roy,

<< Where are the user passwords held - if its in the config (I think its at that level not the catalog) then it will be more awkward. If they're held in UserData then its simpler.  >>

They're held n the configuration.users table so yes it's a bit more awkward.

= Steve

On 18/08/2016 7:44 PM, Steve Gill wrote:
> Hi Roy,
>
> << Where are the user passwords held - if its in the config (I think its at that level not the catalog) then it will be more awkward. If they're held in UserData then its simpler.  >>
>
> They're held n the configuration.users table so yes it's a bit more awkward.
>
> = Steve
>

Hi Steve

It isn't too hard to accomplish (if I understand your requirements).

This is how I have done it:-

1. Designate one server to be "chief" and the rest are "slaves".

2. On "chief" run a JOB that creates an export file containing all the
users, passwords and any other custom stuff you require. I exclude some
special admin users from the file. My JOB runs every 15 minutes.

3. On "Chief" have JOB for each "slave" that pushes the file to each of
the "slaves". Also runs every 15 minutes.

4. Write a simple program that runs on the "slave" which picks up the
export file and uses it to add/change/delete users on the "slave".  This
program runs from the Startup menu and uses a timer, also every 15 minutes.

HTH

Cheers

Jeff

Jeff


I was loath to suggest anything like that because I don't know a way to export a table in an encrypted fashion so the passwords are there in the clear.

Roy Lambert

Roy,

<< I was loath to suggest anything like that because I don't know a way to export a table in an encrypted fashion so the passwords are there in the clear. >>

If you're using the EDB Server, then users shouldn't have *any* access to any of the drives/directories that the server uses for databases, stores, etc.  So, as long as the transport layer uses encryption to transfer the files (like an encrypted connection between EDB Servers with remote stores), then you'll be okay.  Just make sure to delete/overwrite such files periodically (master), or after they are transferred (slave).

Tim Young
Elevate Software
www.elevatesoft.com

Tim

><< I was loath to suggest anything like that because I don't know a way to export a table in an encrypted fashion so the passwords are there in the clear. >>
>
>If you're using the EDB Server, then users shouldn't have *any* access to any of the drives/directories that the server uses for databases, stores, etc. So, as long as the transport layer uses encryption to transfer the files (like an encrypted connection between EDB Servers with remote stores), then you'll be okay. Just make sure to delete/overwrite such files periodically (master), or after they are transferred (slave).

My view on that would depend on the nature of the application and any security implications. At the "die before reading" end of the scale having the passwords sitting in the clear on a hard drive for even a brief period of time isn't a good idea. At the "who cares" end of the scale - well who cares

Roy