mporter Posted November 9, 2011 Share Posted November 9, 2011 If I open a new database in FileMaker Pro and create a table, I seem to be able to reach into a Runtime's .USR file and import data from that Runtime's tables. How does one prevent this? Link to comment Share on other sites More sharing options...
Vaughan Posted November 9, 2011 Share Posted November 9, 2011 Interesting question. Are you the developer? Do you know the account and password that the runtime file is being opened with? Link to comment Share on other sites More sharing options...
Vaughan Posted November 10, 2011 Share Posted November 10, 2011 OK been thinking about this rom a security perspective. The end user can open the file and use the data -- it's their data. What shouldn't they be able to do stuff with it? Or is the issue the ability to directly select it to import from FMP client? Link to comment Share on other sites More sharing options...
comment Posted November 10, 2011 Share Posted November 10, 2011 I am only guessing here, but this could be about: http://www.filemaker.com/11help/html/passwords.13.32.html#1043154 Link to comment Share on other sites More sharing options...
Vaughan Posted November 10, 2011 Share Posted November 10, 2011 Yes I as thinking about that... but that's more about setting up a file as an external data source for relationships, rather than simple old-school importing. Solution might be as simple as flicking the export bit in the privilege set, but my guess is the runtime is opening with the default admin account and password. Link to comment Share on other sites More sharing options...
comment Posted November 10, 2011 Share Posted November 10, 2011 Solution might be as simple as flicking the export bit in the privilege set Alas, that won't work: the export limitation applies only in the local file. That is the hole (or one of them) version 11 was meant to plug. Link to comment Share on other sites More sharing options...
Vaughan Posted November 10, 2011 Share Posted November 10, 2011 OK I understand that. From one perspective, if the user has the authority to see the data (ie username and password to open the database and view the data) then what's the security difference to them sucking it out in an export in one go, as opposed to seeing it one row at a time? mporter: can you explain why you want to prevent this? Does it then become a matter of *convenience*? Link to comment Share on other sites More sharing options...
comment Posted November 10, 2011 Share Posted November 10, 2011 Not speaking for the OP, but suppose you have a database of 20k subscribers. Your support staff are authorized to find a subscriber and view the details to handle a call. That's a far cry from letting them walk out with your entire customer base on a USB flash drive... Link to comment Share on other sites More sharing options...
Vaughan Posted November 10, 2011 Share Posted November 10, 2011 Comment... yes agreed, but it's a matter of convenience only. The user could screen-shot a list view of clients 100 at a time and do it in a couple of days. The export only saves a bit of time and effort. It's like forbidding photography in a building, so instead somebody goes in looks around then makes an oil painting of it. Link to comment Share on other sites More sharing options...
mporter Posted November 10, 2011 Author Share Posted November 10, 2011 Yes, I am the developer. And I just want to prevent an easy mass dump of all the table data. I have invested a huge amount of time amassing and organizing the data and don't want to serve it up to a potential competitor on a platter. Currently, in my Runtime app, although the user has access to the data, there is no view which would let one use the screen-shot method mentioned above effectively and get the same kind of data dump. I'm not looking for perfect security. I know that's not possible. But a FileMaker Runtime does prevent administrative access and keep others from seeing your scripts and other programming structures. Like a regular commercial application does not include access to its source code. I'm just asking if there is anyway for a FileMaker Runtime to also block a mass extraction of all the contents of its internal tables by something as simple as creating a new FileMaker database and reaching into the Runtime's USR file with an import? Seems like a pretty big security hole to me. Link to comment Share on other sites More sharing options...
comment Posted November 10, 2011 Share Posted November 10, 2011 Comment... yes agreed, but it's a matter of convenience only. Eventually, all security is a matter of convenience only. It's more convenient to walk through an open door than having to pick a lock or break down the door. I'm just asking if there is anyway for a FileMaker Runtime to also block a mass extraction of all the contents of its internal tables by something as simple as creating a new FileMaker database and reaching into the Runtime's USR file with an import? Version 11. Link to comment Share on other sites More sharing options...
Vaughan Posted November 10, 2011 Share Posted November 10, 2011 ...Like a regular commercial application does not include access to its source code. Regular applications (like FMP itself) are complied. Customers never get close to the source code. FMP databases aren't compiled. The runtime engine isn't a compiler its a cut-down version of FMP client. Link to comment Share on other sites More sharing options...
mporter Posted November 11, 2011 Author Share Posted November 11, 2011 Regular applications (like FMP itself) are complied. Customers never get close to the source code. FMP databases aren't compiled. The runtime engine isn't a compiler its a cut-down version of FMP client. Yes, I know. I was only making an analogy in the sense that a Runtime database has its programing (scripts, etc) somewhat protected. Do you have an answer to the topic question about how to protect a Runtime's tables from an external import? Link to comment Share on other sites More sharing options...
Vaughan Posted November 11, 2011 Share Posted November 11, 2011 Yes, I know. I was only making an analogy in the sense that a Runtime database has its programing (scripts, etc) somewhat protected. Errr, not really. The only security is to remove administrator access from the file permanently, but that's a bugger because the file cannot be modified after that and any updates will require export/import into a new solution. Do you have an answer to the topic question about how to protect a Runtime's tables from an external import? Comment posted the answer already: use the security file access options in FMP 11 to require full access privileges. http://www.filemaker...32.html#1043154 Link to comment Share on other sites More sharing options...
mporter Posted November 15, 2011 Author Share Posted November 15, 2011 Thanks to both comment and Vaughn for the suggestion to use FMP 11 security file access. However, so far my experiments have not found this to be a solution. First I tried the obvious. If I uncheck the Allow exporting box in Privilege Sets, it does a great job preventing an external file from importing the protected file's table data but it also disables the Export Records script step inside the runtime. That won't work because I am distributing a full-access removed runtime. I have and need scripts that export and import data. If, under File Access, I check the Require full access privileges to create references to this file box, AND ALSO, under File Options, disable Auto login, it will keep another file from getting in to import without entering the account name and password. However, I want the user to have the convenience of an Auto login. Besides, if there is no Auto login, I have to give the user the account name and password anyway. So that doesn't seem to work. I have also experimented with custom privileges options but can't seem to find a way to block an external file from importing data out of the protected file's tables that doesn't also disable the user's access to the data within the runtime. Maybe there is something simple I am overlooking here. Link to comment Share on other sites More sharing options...
comment Posted November 15, 2011 Share Posted November 15, 2011 Under File Access, you should check both Prevent opening with earlier versions (pre-FileMaker 11) AND Require full access privileges to create references to this file. This will prevent exporting your file's data using a reference file. If I uncheck the Allow exporting box in Privilege Sets, it does a great job preventing an external file from importing the protected file's table data but it also disables the Export Records script step inside the runtime. That won't work because I am distributing a full-access removed runtime. I have and need scripts that export and import data. Your exporting scripts should be set to run with full access privileges. Link to comment Share on other sites More sharing options...
mporter Posted November 15, 2011 Author Share Posted November 15, 2011 Under File Access, you should check both Prevent opening with earlier versions (pre-FileMaker 11) AND Require full access privileges to create references to this file. This will prevent exporting your file's data using a reference file. Your exporting scripts should be set to run with full access privileges. Thanks. Setting the export scripts to run with full access privileges does the trick. I thought there was something simple I was forgetting. Link to comment Share on other sites More sharing options...
Recommended Posts
This topic is 4552 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