Jump to content

soulicious

Members
  • Content Count

    67
  • Joined

  • Last visited

Community Reputation

0 Neutral

About soulicious

  • Rank
    member

Profile Information

  • Location
    Whittier, CA
  1. After going through the logs, the logs read that the "cache will flush every 1 minutes". Apparently, the reading within FM server on the Database Server-> Databases tab is some sort of "typo" or misreading. I guess this is a non-issue then.
  2. Hello, I have recently had to re-install our FM Server and for some reason, the cache flush distribution interval is set to 03:01 (3 hours and 1 minute) and it won't change. I don't understand why it is doing this. I have tried adjusting it, saving it, and restarting the server, but it just stays at 03:01. Has anyone else had this problem? After a few initial searches, I have not seen this come up anywhere else. Any clues on how to fix this? Thanks in advance!
  3. Hi James, "Account based logins" simply refers to the built in FileMaker security setup under File->Manage->Security where you can add accounts and control their access to the database very granularly via privilege sets. The "Guest" account that you are using is one of these accounts. You can add as many accounts as you need and control groups of their access via the privilege set. These native "account based logins" (as opposed to table based logins) also allow PHP sessions to authenticate and connect to the database. I'm not using webdirect (the licensing is too expensive for lots of concurrent users) so I can't speak specifically on how web direct works, but I can say that I do something similar with a user table and I keep "extra" info about users and their session in the user table. However, it turns out that using the built in security/accounts for authentication and security gives me way better control of each user's access within my whole solution. Since you can even use calculations in a privilege set, you can control just about anything under any circumstance! All the "extra" user session info you need can still reside in your user table, but you don't have to rely on that table for security. Hope that helps! By the way, I'm from Fresno too (though I live in SoCal now). Did you grow up in Fresno (I went to Bullard High)? How's the FileMaker community there? Best wishes!
  4. Hi Comment, I am using the FileMaker PHP API to access FileMaker Server 11 Advanced, so I guess that is considered custom web publishing. What are you trying to "reconcile"?
  5. SOLVED! I don't know why it didn't dawn on me at first, but I ended up finding a clean and simple solution without needing to upgrade (not sure that upgrading would have solved the issue anyways since I specifically was looking for a relationship based solution and not portal filtering). As you can see in the screen shot attached of my relationship between the tables, the kp_ID_Patients in the "Patients" table occurrence is related to the kf_ID_Patients in the charges table. I simply created 2 new fields in the charges table called kf_ID_PatientsCurrent and kf_ID_PatientsArchived. I then relate the kp_ID_Patients field in the Patients table occurrence to the kf_ID_PatientsCurrent field. When this field is populated with the Pt ID, it means that the charge is current. I create a second table occurrence of the Patients table (which I already had anyways as you can see in the screen shot), and simply relate this to the kf_ID_PatientsArchived field. When the kf_ID_PatientsArchived field is populated with the Pt ID, it means that charge is now archived. Each table occurrence only relates to the charges that meet the relationships requirements...thus "filtering" between "Current" and "Archived" charges! It is very simply in a script step to simply fill in the PtID in the proper field (especially since I already had a script marking an "Archived" field in the Charges table as true...now I don't even need to mark it archived, because by definition the field populated with the ID is based on whether it is considered archived or not). It is also very simple to "view" only the archived or current charges by simply viewing the layout that corresponds to the Patients table or the Patients 2 table. This also works via PHP! Hope this helps someone else down the road on dealing with "conditional" relationships!
  6. Hi Comment, Thanks for responding. In answer to your question explaining this statement: I was able to "filter" the different results between what the two portals show by using portal filtering so that in FileMaker the "current" portal only showed current charges and the "archived" folder only showed archived charges. However, when I do a query from PHP for the data coming from these portals, it still shows me "All" the charges instead of just the filtered data. In any case, I have found a good solution for my issue which I will post in a separate reply within this thread. Thanks!
  7. Hi Agnes, thanks for your response. Upgrading is not an option right now, but thanks for the tip. As far as the relationships go, I do want to show the charges from the Patient's perspective. Since I have 2 table occurrences for Patients, you're saying I need another table occurrence for Charges? How do I relate the "statusA" and "statusC" fields in Patients...relate them to which field in Charges? Do I need to relate both the Patient IDs and the status fields? Thanks for your help! Sorry for all the follow up questions, but I don't think I fully understood your explanation.
  8. Hello, I'm having trouble with the initial set up of my relationship. For the most part it is a simple 3 table (one to many...many to one) design with a sort of "line-item" table in the middle. There are two sticking points for me:1) I would like to set up the relationships based on the "status" of the line items and 2) the portal should only show records that belong to the user logged in. I am attaching a picture to show the simple table relationship between my current tables: user, charges, patients. I have set up the privilege set so that the user can only see his/her charges when logged in, so I think I have sticking point 2 taken care of without requiring the relationship to handle it. The problem with sticking point 1 is that I want the "Patients" layout to contain 2 portals, one pulling the charges with a "current" status. I would use table occurence "Patients" for this portal. The second portal would be for showing the charges with status "archived" and would use table occurence Patients 2 (normally I would just use portal filtering to get the results I need, but I am calling the data via PHP and portal filtering doesn't seem to apply while using PHP, so I need to figure out how to do it based on the relationships). How can I incorporate the status of the Charge into the relationships between the patients and their Charges where the Patients table is related to Charges with the corresponding kf_ID_Patients and ChargeStatus = "Current" and at the same time where the Patients 2 table is related to Charges with the corresponding kf_ID_Patients and ChargeStatus = "Archived" ? Currently the patients are simply related to the charges via the Primary to Foreign key relationship, but this allows the portals to "see" all the charge records for each patient. I need them to reflect only the charges dependent on the appropriate status. Thank in advance for your help! I feel so close, yet I can't seem to visualize how to do this!
  9. Just wanted to quickly report back in order to "close" this thread. Everything is working as expected now! I "reset" my connection to the FileMaker server by "re-installing" the PHP API and got back to logging in via filemaker accounts (instead of a table login). Now the privilege set security is working! Thanks again for your time, Doug!
  10. Thanks Doug. It seems before I tackle the account security issue, I have to get my login situation fixed. Even though I switched to the account based login (as opposed to table based), it is actually still logging in via the table. I've verified this by trying to login as a user defined in the accounts where my login is rejected. However, when I add that user to the user table, the login works. Back to the drawing board... but hopefully fixing the login issue will also solve my account security issue!
  11. Thanks for the response Doug. I went ahead and converted my project to be account based, but now it seems I have a new problem... Converting to account based access works well in Filemaker. I have the privilege set calculation set to Get(AccountName) = RecordOwner and when I log in to FileMaker it does as expected: the account owner can only see their own records. All other records are viewed as <no access>. However, when I log in to the web interface, it doesn't find any records anymore; even if I log in as administrator. If I "echo" the $_SESSION info, I find that it is recognizing the correct account as being logged in. Not sure where I'm going wrong... Any help is appreciated!
  12. Hi Webko, I'm struggling with a problem that it seems you have solved in the past (based on the quote above). May I bother you for a few details about how you do it? I have a PHP (PHP API) web interface using a table-based login that I need to set the security in such a way that the current active user can only see their own records. This is simple if I used an "Account Based" login, but since my database will have many users, I went with a table based login for ease in management. The problem then, is that the Get(AccountName) always return the "web_Access" account. I can't wrap my head around how you use the web_access account to match a user in the WebUser table which then can be used for setting the privilege set criteria. I haven't been able to come up with a way to say: if the user is "web_access", then make the web_access = ActualActiveUser. Then I could use this info to limit viewing within the privilege set by limiting record viewing to ActualActiveUser = RecordOwner. It sounds like you are using something on the PHP side to help with the logic..? Any help is greatly appreciated!
  13. Hello FMP security experts! Is it possible to lock down records "per user" in a database that is accessed via a PHP web interface that uses a table based login (as opposed to an "Account based" login)? The database needs to allow for multiple users who can only access their own records. This is no problem with an account based solution where the concept: Get(AccountName) = RecordOwner is used within the privilege set to only allow the active user access to his/her own records. However, since this solution needs to scale to around 100 users, I considered using a table based login in order to ease account management for that many users. The problem is that since the table based login uses a single "default" style login, let's call that login "webuser", if I use Get(AccountName), it's not actually reflective of the user actually logged in! I just can't seem to get my head wrapped around this. I tried using a field called "AccountName" in the User table so that AccountName = RecordOwner could still be used for the privilege set security setting, but since the records are always related to the AccountName of the user that created them, this equation (AccountName = RecordOwner) always rings true and allows for all records to be viewed by everyone logged in. The unique factor in the Get(AccountName) security paradigm is that the active "Account Name" might not be the same as the Record Owner name which allows or disallows access. However, using a field in the User table creates a scenario where if that User and their records are related, they are always related. I haven't been able to come up with a way to say: if the user is "webuser", then make the current account = the actual active account. Then use this info to limit viewing within the privilege set. Is this scenario even possible at all using PHP with table based logins? If not, I'll stop trying, lol! If it is, I need some help seeing how to do it. One last question, even if it is possible to do this via table based logins, should I be using Account based logins anyways? Thanks in advance for your help!
  14. Ah, got it. Thanks! So far so good I think: the field/element that dictates the "ownership" comes in as <no access> if a different user/attacker hits that record, so if I understand you correctly I should be good because the "attacker" is not able to manipulate the data in that field and thus can't get access to the record! Thanks again for your help and sharing your knowledge with the FileMaker community!
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.