Working with Access Rights

[DOntquIT]

Re: Working with Access Rights

Already done, see this post.
http://msgboard.alphasoftware.com/al...ad.php?t=73650


.

Thank You Steve.That Helped :)

[DOntquIT]

Re: Working with Access Rights

Can i import jus the websecurity tables from server other than importing all the pages and components ?
i have gone through utilities in websecurity where it mentioned that , select profile to import files..

Is there a way that i can jus import only websecurity tables.
Alternate way i can do is to create one dummy project import websecurity tables from server into that project and from there i can import to my project.

But before procedding that way , jus want to find out about other possibilites.

[Steve Wood]

Re: Working with Access Rights

I know what Alpha/Jerry would say - "at your own risk". Personally, even though I know I could import or otherwise use those security tables, I don't touch them. I don't believe there is anything you want to do below that you cannot do with the normal functions, not that I figured it out. I would not even import information from the security files into my own tables. The major reasons are a) I don't want to compromise my security, b) I don't want to second guess what is in those tables and c) Alpha could encrypt or change how those tables work with any update and d) I don't want to expose to any significant degree how security works.

[DOntquIT]

Re: Working with Access Rights

Can i import jus the websecurity tables from server other than importing all the pages and components ?
i have gone through utilities in websecurity where it mentioned that , select profile to import files..

Is there a way that i can jus import only websecurity tables.
Alternate way i can do is to create one dummy project import websecurity tables from server into that project and from there i can import to my project.

But before procedding that way , jus want to find out about other possibilites.

The reason i asked this is,

we have implemented our project in client place and they started test run on it.
During implementation, we assigned "testing" as default password for all the user, which they changed once they started using system.

Now after implementation, when ever there is changes requested and when we republish the files (including web security tables) , all password that changed by user changing back to default password "testing".

So we thought of importing web security table data alone to our projects and publish whole thing back to server.

[NoeticCC]

Re: Working with Access Rights

Take a look at the pages.SecuritySettings file that is published to the web root of your app, that is the file this refers to. (Plus the project.SecuritySettings file too)

[Steve Wood]

Re: Working with Access Rights

Once you go live and the software is self-maintained by the client, you should never republish the security tables. You have to manually check a box in order to publish security, so you should not check that box. Is there a special reason you want to republish the security?

FYI - I unsuccessfully lobbied for a "lockdown" checkbox somewhere far away from the publishing process. You could check a box on a completed project and it would NEVER publish security tables (unless you unchecked the lockdown box). I think is is frightning to have a publishing process where a simple mistake can cost you your entire user list. My request got turned down.

[NoeticCC]

Re: Working with Access Rights

FYI - I unsuccessfully lobbied for a "lockdown" checkbox somewhere far away from the publishing process. You could check a box on a completed project and it would NEVER publish security tables (unless you unchecked the lockdown box). I think is is frightning to have a publishing process where a simple mistake can cost you your entire user list. My request got turned down.

What would be nice is a simple check where it compares the user and group list from the server with the local one - if users/groups exist on the server that do not exist locally, or if passwords or email addresses have changed on the server, synchronise instead of just overwrite.... Or at the very least point out the differences and allow the user to cancel.

[Steve Wood]

Re: Working with Access Rights

simple check where it compares the user and group list from the server with the local one.

Working on it! It's a vital element because the security is, by nature, a hidden beast. But to do it, I have to slightly break one of the 'rules' I listed earlier.

[DOntquIT]

Re: Working with Access Rights

Once you go live and the software is self-maintained by the client, you should never republish the security tables. You have to manually check a box in order to publish security, so you should not check that box. Is there a special reason you want to republish the security?

We added few employees manually (since its only 3 more emp need to be add other than existing) to all the three web security tables after implementation because the project where they can add user by system in not yet implemented.that module we are plannin to do next month only since its client reqirements.

Thats the reason i asked for it.but i feel its better to avoid doing manually to overcome all this situations.

Thanks for Info provided.Really usfull informations

[Steve Wood]

Re: Working with Access Rights

I should temper my use of the word "never". I was thinking about a totally live system where users were registering and maintaining their profile online. In that case you would not want to pub security because you would wipe out their changes.

Another method is to use Utilities under Web Security to import the existing security from the live site, update manually, and republish security. I am so mistrusting of that mistake-prone process I would always make a copy of the live tabels first. In fact, I backup my live websecurity*.* and other critical tables every day and keep archives for ten days.

[DOntquIT]

Re: Working with Access Rights

Can i import jus the websecurity tables from server other than importing all the pages and components ?
i have gone through utilities in websecurity where it mentioned that , select profile to import files..

Is there a way that i can jus import only websecurity tables.
Alternate way i can do is to create one dummy project import websecurity tables from server into that project and from there i can import to my project.

But before procedding that way , jus want to find out about other possibilites.

Yes, thats my question too.
when i use that import option , does it import only websecurity or does it import the whole project to the current system?

and if i jus copy the pagesecurity.securitysettings from live site, to my project actually what will happen ? does it gonna modify my security tables ?

[Steve Wood]

Re: Working with Access Rights

The Web Security > Options only imports security Users and Groups, that's all. It does not import the Pages security. But I should not give any advise in this area -- I know what will happen if you move around security files since I have done it. It may work at one point, but then completely screw up your security in the target application at another point.

A simple example may help:

Say you have two copies of the same application that are exact clones of each other. Say you add a security Group named ADMIN to each of them, or say you add a User named Steve to each of them -- at this moment the two sets of security files will be completely incompatible. If you copy either set to the other, your security will be hosed in the target application and you will have a bunch of work to do to fix it.

Going back to your original post, why not create an A5W page using the built-in security functions and call that page from your SQL login screen with parameters that establish security in Alpha?