dwolfe Posted December 15, 2000 Posted December 15, 2000 Got an odd little behavior problem with the web security databases that I thought I'd run by everyone here to see what you thought. I have 2 FMPro 4.1 clients runnings the web companion. I have recently switched over from regular FM security on all web databases to web security. I'd like to mount the security databases on our FM Server and then have each FMPro client load the security databases through a start up script. That way I have one security database that both clients use instead of two separate local databases that I have to update in tandom. I've taken this approach and the FMPro clients appear to acknowledge the Web Security.fp3 database as mounted and open but I can see that when someone hits a web database through the web companion because I can see that database shift and search as web visitors access various databases. As I understand how the Web Security.fp3 database process works, when a call come in from the web companion for security info, a search is performed in the Web Security.fp3 database for a record with a matching name as the database that's being accessed by the web user. When that record is found, the security info is given to the web companion and everyone is happy. The problem is... when the FMPro clients load the security databases from the FM Server, they can not successfully find matching security records for the databases being accessed on the web. If I load the security databases from the local hard drives on the clients, everything happens as it should. Is there a specific reason why the Web Security.fp3 database (and two related databases) can't be loaded from an FM server? Why would the FMPro clients not be able to look up database security records when the security database is not loaded locally? I have given all the databases a password but they doesn't keep them from operating when the databases are loaded locally. Thanks for the info and insite.
Anatoli Posted December 15, 2000 Posted December 15, 2000 Web Security databases should be not located outside of Web Security folder and the Web Security.fp5 (or fp3) cannot be renamed. All web pages must be in Web folder. That is my conclusion for past 2 years.
dwolfe Posted December 15, 2000 Author Posted December 15, 2000 I wouldn't think it would matter where the security database gets loaded from since it's just data. If the database hasn't been opened by hand then the web companion gripes that it can't find it so it's obviously (IMHO) not "hard coded" to look for it in the Web Security directory or it would open it itself. Plus, the web companion searches the security database no matter if it's loaded from the local Web Security directory or an FM Server. The only difference is, when the security database is loaded from the FM Server, it doesn't find security records for the databases being accessed. It comes up with 0 records in the found set and spits out an error to the web client. And I knoooooowww that there is a record in the security database for the database(s) being accessed.
Vaughan Posted December 17, 2000 Posted December 17, 2000 Well it sounds like it matters then, doesn't it.
Anatoli Posted December 17, 2000 Posted December 17, 2000 quote: Originally posted by dwolfe: ... so it's obviously (IMHO) not "hard coded" to look for it in the Web Security directory or it would open it itself... I was trying hard with v. 4 to put Security Databases somewhere else and/or rename them WITHOUT success. I didn't try that with v 5 yet.
dwolfe Posted December 18, 2000 Author Posted December 18, 2000 Did you get the same results as I am seeing? 0 records being found in the Web Security.fp3(5) database when it is loaded from someplace other than the Web Securitydatabases directory?
Anatoli Posted December 19, 2000 Posted December 19, 2000 It looks like in v. 5 it is not "Hard coded". My Security databases started from different locations (the same disk and different disk) did performed well their duties. The test was done on local IP connection.
Recommended Posts
This topic is 9008 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now