Which SecuritySettings file is the culprit for breaking security on production server?

[RichCPT]

I see the following SecuritySettings files on the production server:

Guid.SecuritySettings
pages.SecuritySettings
Project.SecuritySettings
ProjectProperties.projectProperties

It seems that one or more of these cannot be copied from my development workstation to the production server.

Do any of the above tables get set up one time upon initial setup and then from then on left as is? Or, do all four tables need to be updated at the same time? If they have to be updated at same time then why has my production server decided all logins are now invalid after replacing those files with a new set?

[Steve Wood]

Re: Which SecuritySettings file is the culprit for breaking security on production server?

By production system do you mean your Alpha project files (which would not have the guid file) or a published copy to localhost (or other local destination)?

And when you say logins are invalid, does it say the password is not correct or does it let them log in but then say they are not authorized to access a page or similar?

Typically you can copy all files from a locally published copy up to some other location -- provided that local copy is exactly the same as your target production copy with respect to the page and component security settings, etc. The guid file is the only file not residing in the Alpha project and is generated during publishing time. The one you probably already have in your production copy does not need to be overridden. Another thought, I don't know which file stores the password encryption key, but I am sure if your passwords are encrypted, then you would have to be sure your locally-published copy had the same value for the password encryption as your production environment.

[RichCPT]

Re: Which SecuritySettings file is the culprit for breaking security on production server?

Thanks Steve. I was referring to another server that is not at my site. All attempts at logging into the system were receiving the error, "Login Information Incorrect". This was from a "login" component.

Turns out the problem had nothing to do with the files I mentioned in post # 1. The problem was that the "a5_application.a5i" from my locally published dev system got carried over to a production server.

For any who cares to answer:
Wouldn't it be easier to update AA Web App servers if it were possible to deliver a zip file or some kind of install file to the administrator of that server and let he or she run a process that is built into Alpha Web Server to load the web app?