Yesterday’s post was about putting password protection on the Edit Type button in the Properties dialog. It was great to see so many comments and page views from people interested in this.
Here is another part of limiting access to modifying families – preventing unauthorized users from opening family files in the Family Editor.
This could be combined with the Edit Type password requirement shown yesterday but here are a few issues that would need to be resolved. It would be great to hear your ideas on these.
- Should these restrictions be applied to all families? If not, how should specific families be marked? Would a Yes/No type parameter in each family make sense? (It would be nice to able to add a family parameter instead of a type parameter, but the Revit does not support that.) Another option would be to mark families by storing some extensible storage data, but that introduces its own complexities.
- Should there be password restrictions on both opening existing families and creating new families?
- If I made this available as a single compiled application, everyone who downloads it would have the same application with the same password. Is this a deal-breaker?
Ideally every company would be able to set their own password, but having me generate a unique DLL for each firm seems a bit cumbersome for everyone.



Harry
Revit security is non existent
That is why people care
I am Working with the p rug group to try and make a class on this for next year
Your methods via API are great
What would be fantastic is if there was a way it was embedded I. The Revit file
Because if I give the model to a client then they could open the family because they don’t have the API installed
Is there a way?
Thank you
Marcello
Comment by M S — January 23, 2013 @ 12:31 pm
Hi Marcello,
I don’t think the API can be used to embed security in the RFA file. We can create document macros to embed a macro in a Revit file, but Revit’s Macro Security settings do not enable macros by default, and the user has the option to disable them. There are good reasons for this, as the API Wiki explains, but it makes the API unable to provide the security desired.
http://wikihelp.autodesk.com/Revit/enu/2013/Help/00001-Revit_He0/3032-Customiz3032/3207-Automati3207/3224-Macro_Se3224
“Macro Security
You have the option to enable and disable macros by default. This protects your work and computer from running dangerous malicious code unexpectedly. When working with macros, it is important to be wary of the risks involved with their vulnerabilities. Only run known macros from trustworthy sources.”
Comment by harrymattison — January 23, 2013 @ 12:42 pm
Couldn’t the password be stored in a text file in the same location as the DLL? This way we can set our own office password. I think it might be fine that it’s an unencrypted text file because most users won’t know to look in the DLL location. Just one thought.
Comment by nmiller — January 23, 2013 @ 12:34 pm
Yes, it could be done with a text file next to the DLL. And if that text file doesn’t exist then a default password could be used. Thanks for the suggestion.
Comment by harrymattison — January 23, 2013 @ 12:35 pm
could you set up the family to “fail safe”? For instance: if a password txt file [or the macro?] doesn’t exist on the machine it won’t allow the user to open the family.
Comment by Russ — January 23, 2013 @ 12:54 pm
My company is interested in the ability to lock the project for deliverables. We are willing to provide an editable model that has disclaimers about content having been modified, but the original deliverable they want to be able to lock. Would that be possible?
Comment by David Raynor — January 23, 2013 @ 12:59 pm
Hi David,
This question is similar to the one that Marcello asked in an earlier comment. Unfortunately Revit and its API do not support this. A macro can be saved in a document that would prevent modifications, but Revit’s default is to ask users if they want to enable document macros, so a user who wants to avoid this restriction could easily turn off the macro.
Harry
Comment by harrymattison — January 23, 2013 @ 1:03 pm
G’day Harry
is it possible to set the Marco in the Revit family that prevent people opening it without the DLL present? is that maybe a way to add security to the companies families?
Comment by Dom Martens — January 23, 2013 @ 4:12 pm
a protection on editing families for internal use would be great. Each firm has its complex families, where only the people who know what they are doing can mess around with. So it’s not for protecting your families for the world, but for internal use.
1. protect a family with a yes/no type parameter is the best option i think
2. don’t know exactly what you mean. Families from your library should be protected (by choice)
3. With a bit of explaining everybody should be able to create its own DLL…
Comment by Arno — January 24, 2013 @ 2:14 am
1.) I think a Yes/No parameter makes sense as a type property. If it’s checked (password enabled), it’s not like anyone could mess with weither it’s checked or not. They’d need a password to do so. That makes the most sense…and seems the most basic and straightforward.
2.) As it relates to new families, ideally I would say that all family templates would contain the parameter but would be turned off by default.
3.) I don’t think that would matter as long as it’s easy to change the password.
Comment by David — January 24, 2013 @ 7:33 am
How about project security? We would be very interested in something that enforces the opener / referencer to tick a box, agreeing licensing terms, haviing read disclaimers etc. We’ve had hairy situations where they started building off of an early cost model…
Comment by Balazs Trojak — January 28, 2013 @ 11:43 am
Hi Balazs,
This is an important and valid topic, but unfortunately Revit and its API do not have good support for this. A macro can be saved in a document that could prevent modifications / show licensing terms / etc. But the default in Revit is to ask users if they want to enable document macros. So the macro could be added to the project, the user opening it would get a prompt from Revit asking if they want to enable document macros, and the user could click to disable the document macros which would prevent the project security mechanism from running.
Harry
Comment by harrymattison — January 28, 2013 @ 11:49 am