Just starting and already a question

Is it absolutely necessary to test SecurityAssist on a local server?
I have built a new site and it's currently in a folder /newsite/ on the client's domain, for testing. I want to add SecurityAssist functionality now. I have created a database with a table 'users' but using the Wizard, I keep getting "unidentified error" when testing the connection. Reading through the forum, it looks like you encourage people to install a server like XAMPP for this purpose, which looks to me like lots of extra work.

I went back to the site server settings and ticked the "testing" as well as the "remote" checkbox. Then opened the SecurityAssist Wizard again. I think I got a bit further this time.

Now I get a 404 error, saying either there's no testing server (but there is) or, that the testing server specified for the site does not map to the .........MMHTTPDB.php URL.

I can see that the _mmServerScripts folder has landed in the /newsite/ folder so shouldn't everything be mapping OK? Or does it need to be in the root folder? Even when I place it in the root folder I get the same error.

I have my root folder in DW as /newsite - could this be the problem?

It is recommended to use a local testing server for a number of reasons, the two biggest ones are:
1) Many remote hosts will restrict access to the MySQL Server by outside connections. meaning that the MySQL server will not allow your computer to connect to it, only the hosts server can connect. Some hosts will offer a way to add your IP address to the allowed list to get around this, but some dont.

2) Even if you can get a connection to the remote MySQL Server going in Dreamweaver, it will frequently get dropped by Dreamweaver and cause the extensions to hang on trying to reestablish the connection.

Setting up the local testing may seam like a lot of work at first, but it greatly improves the performance of Dreamweaver to connect to a local database over a remote database.


The error message you report in the second message means that the Web URL you specified in the server setting cannot be connected to.

<sigh> OK, thanks.

A little feedback, if I may...
1. You might update your knowledge base for Dreamweaver CS5.
2. You recommend installing the latest XAMPP (1.7.4) when anyone running 64 bit will end up in trouble. I finally installed 1.7.3 and so far, so good.
3. Please let registered users of your forum submit posts without the captcha requirement! Very annoying.
4. You advertise SecurityAssist as working on static sites. Sounded too good to be true? It was.
Having said all that, I'm now looking forward to installing SecurityAssist! Thanks.

Another question: you say in the GSG "An example of an appropriate visitors database can be found in the SecurityAssist Solution Recipe Files found in your Download Center."
I have downloaded the zip file but it's not clear exactly where the database is.

And another one: my remote server was fine until I set up the local testing server. Now the testing server is fine, but when I 'put' a file, I can't get it to go to the remote server. I need to run both because while I'm setting up SecurityAssist my client is checking through the beta site (on the remote server) and sending me changes.

<5 mins later> it looks like I've fixed this one, problem is I'm not sure how. I think I toggled one of the icons in the Files box.

I will forward your comments to the documentation team.

the database is in the datasources folder. if you are using PHP, you may want to see the "How to import a MySQL (.SQL) file to your database" tutorial on the learning resources page.

Thanks Jason. Now I'm looking for:
"User Level Authentication Solution Recipe available from the SecurityAssist Support page"

And in case, when I find it, it doesn't help with this question, I'll lay it out here as because of the time difference I can only ask you questions overnight...

I am trying to set up a password system for a medical research organisation and the client wants a very complex password system. There are many different user groups, ie

Advisory Board Members &#8211; access to ALL PAGES of the website
Scientific Committee Members &#8211; access to ALL PAGES
Operations Secretariat Members &#8211; access to ALL PAGES
TMC Members &#8211; password access to trial specific TMC and Steering Committee, Publications Page and News Page
Steering Committee Members/Trial Sites &#8211; password access to trial specific Steering Committee, Publications Page and News Page
Endpoint Adjudication Committee Members &#8211; password access to trial specific EAC, Publications Page and News Page
DSMB Members &#8211; password access to trial specific DSMB, Publications Page and News Page
AKTN Members &#8211; password access to Member Resources, Publications Page and News Page.
General public / nephrological community &#8211; access to non password pages only.

"Trial-specific" - There are about ten different trials. So there are ten TMCs, 10 steering committees, etc etc.

Except for the users with site-wide permissions, all the user groups are to have access to various files across various folders but no-one has access to all the files in any folder. I thought of setting up a folder for each user group, but that would require having duplicate files in many folders which would not be a good idea.

I'm feeling a bit overwhelmed at the moment - any ideas or pointers would be much appreciated!

with security assist 2 releasing yesterday, the tutorial for User level authentication has been moved into the archived documentation section of the security assist support page.

the user level authentication tutorial should help with the system you are trying to create, the example given in the tutorial is for 3 levels, but this can be expanded to as many levels as you need.