Users & Groups Issue

[Tom Cone Jr]

Re: Users & Groups Issue

Stan, I agree with Garry. Your approach is much simpler than what I was thinking of... Thanks.

[gmeredith17]

Re: Users & Groups Issue

Unless I'm mistaken this still doesn't preserve the current passwords. Not a big deal for a small company but if you have hundreds of employees then this would inevitably be a big time waster. Also many would consider emailing the passwords as a security breach. All this would depend on how often an update was provided. Once a year might be seen as acceptable but depending on the nature of the software you may provide updates quarterly or monthly.

So Stan's method is good and probably the best that can be achieved with the current tools but Alpha really need to look into this and either provide the tools for developers to copy or retain the passwords or move the information to a different location. This may sound easy and in principle it is but I'm guessing they embedded the passwords (encrypted I hope) with other data to make it harder for someone to obtain the passwords. If the passwords were stored in a separate table then it would be easier for someone to find them and crack the encryption.

Maybe a quick and easy solution for Alpha would be to give the developer the choice of saving the passwords in a separate table of their choosing if desired. It would then be down to the developer to encrypt and maybe add bogus data with it for added security.

[Stan Mathews]

Re: Users & Groups Issue

Alpha really need to look into this and either provide the tools for developers to copy or retain the passwords or move the information to a different location.

Not sure I understand. I was trying to design a workaround for Keith who wanted, at first glance, a way to quickly set up and import a complete security framework.

As I understand it, if you use the built in export which creates an adb you can preserve the passwords as well. Emailing that should be safe as the passwords are likely encrypted there, as you note.

The client sends you that file, you update your update with their security, you send the update back.

I'm probably missing something because I don't use any of this.

(And thanks to Tom and Garry for your kind words.)

[gmeredith17]

Re: Users & Groups Issue

Hi Stan,

My response was in reference to the original question

I am trying to find a way to give my users an update to my software without overwriting their "Defined Users and Groups". I am installing using Astrum and do not include data files or the runtime files for the update. Problem is, after installing the update their users/groups are deleted. Is there a solution? Thank you,

Don

It may well be me getting mixed up with the detour the thread took.

[Bill Parker]

Re: Users & Groups Issue

Here is a very simple approach to solve the problem.

I create a 2nd database in the application directory (in my case called security.adb) and define the initial users and groups. In the application database, set security to "use a shared security database" and point it to the database you just created.

The functions in the application for users to manage users and groups still work as before, they automatically operate on the security.adb. Now you can replace the application .al* files without replacing the security info.

My security.adb has no control panel objects and it never needs to be opened by the developer or user after it is created.

Bill.

[Tom Cone Jr]

Re: Users & Groups Issue

Bill, that's intriguing.

1) do you have to mirror the setup on the remote development machine?

2) when you network optimize the application database do you have to network optimize the security database, as well?

Thanks.

[DaveM]

Re: Users & Groups Issue

One thing this thread taught me. I am so glad I built my own security system years ago and never changed it to the Alpha security as they have it now.

WOW, what a mess this looks like.


.

[Bill Parker]

Re: Users & Groups Issue

Bill, that's intriguing.

1) do you have to mirror the setup on the remote development machine?

2) when you network optimize the application database do you have to network optimize the security database, as well?

Thanks.

1) Yes, but that is just the security.al* files in the same directory. Actually this would be created on the development machine and copied to the target machine/server. After that, user and group updates in the target environment would not be refelected in the development environment unless security.al* was copied back.

2) No.

Bill.

[aschone]

Re: Users & Groups Issue

I am curious as to why the AL* files need to be replaced with your update? What was it in the AL* files that has been changed?

When I update my databases I write an update script. All changes to the AL* files are done via xbasic. The only files that I replace are the data dictionaries for the actual tables and sets in the database.

The only time I have come across needing to replace the AL* files was when I wanted to push out a new toolbar to all of my databases. It was at this time that I wrote the function to import/export toolbars, thus eliminating the need to actually replace the AL* files.

[DaveM]

Re: Users & Groups Issue

Andrew,

Doesn't that also lead to: If all your functions and scripts are put in an aex that you would still not have to overwrite the original al* files? And, Any added tables could be picked up by way of the autoexec on start up?? forms, reports etc are all in the tables files anyway??


No, I am not changing what I have, but maybe it will help others?

Using astrum installer, you can choose to never overwrite. It would still be a good idea to backup the al* files before an update.



.

[aschone]

Re: Users & Groups Issue

Andrew,
Doesn't that also lead to: If all your functions and scripts are put in an aex that you would still not have to overwrite the original al* files?

Why not just replace the AEX file? Why would this require changes to the AL* files? I currently do not compile my scripts to AEX so have never needed to address this.

And, Any added tables could be picked up by way of the autoexec on start up?? forms, reports etc are all in the tables files anyway??

Any added tables, table structure changes are all handled via the update script. Form, reports, etc can be handled a couple of ways. One would be to just overwrite the data dictionaries for the tables affected (this is what I do).

Another method would be to use export the report/form/etc from the updated data dictionary and import into the live data dictionary. Once version 10 is released I will begin investigating this method because version 10 has built methods to export just the form/report/etc.

No, I am not changing what I have, but maybe it will help others?

I agree, its not wise to fix what is not broken

Using astrum installer, you can choose to never overwrite. It would still be a good idea to backup the al* files before an update.

I think the OP has a need to replace/update the original AL* files hence the reason for the post regarding issues with overwriting currently established security settings.

[DaveM]

Re: Users & Groups Issue

Why not just replace the AEX file? Why would this require changes to the AL* files? I currently do not compile my scripts to AEX so have never needed to address this.

YES! I don't compile mine either as yet and have no problem with the al* files.

[QUOTE]
Any added tables, table structure changes are all handled via the update script. Form, reports, etc can be handled a couple of ways. One would be to just overwrite the data dictionaries for the tables affected (this is what I do).

Another method would be to use export the report/form/etc from the updated data dictionary and import into the live data dictionary. Once version 10 is released I will begin investigating this method because version 10 has built methods to export just the form/report/etc.

[/QUOTE]

Precisely


I hope Don has figured out at least a couple of ways that will save his app problems.


.

[Bill Parker]

Re: Users & Groups Issue

Maybe some confusion about the .al* files from my description?

The security tables are stored in the alb, alm,alx files. The original problem was neding to preserve the local users and groups when the developer made changes to the application al*.

In my approach the security system is removed from the application database, so anything the developer does to update the application has no impact on local changes a user has made to users and groups.

A second database is created in the application directory to store the security information. This database never needs to be updated by the developer.

The developer will apply application updates to the user's copy of the application database in any way they like. This could be by aex, or replacing the application's al* files, or replacing individual objects. Again, this has nothing to do with the security info that is now in its own database (yoursecurityfile.adb).

Bill.

[Stan Mathews]

Re: Users & Groups Issue

Then you developed your own form/xdialog to handle the inevitable additions, deletions, and changes or do you just provide access to A5_USER_GROUPS_DIALOG()?

[Bill Parker]

Re: Users & Groups Issue

Then you developed your own form/xdialog to handle the inevitable additions, deletions, and changes or do you just provide access to A5_USER_GROUPS_DIALOG()?

There is a button on my utilities ment to Define Users. This button is hidden if the user is not in the administrator group.
a5_security_option("DefineUsersandGroups")

All users can change their own password.
a5_changelogonpassword()

This was the original capability I had. Then I discovered the same problem that updating the application was a pain with the security info in the application database. So I moved security info to its own database. None of my application code dealing with security had to change when I made the switch.

I nave written no forms and just use these a5 calls.

Bill.