More on Family Security – require password to open family files

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.

  1. 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.

  2. Should there be password restrictions on both opening existing families and creating new families?
  3. 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.
About these ads

19 thoughts on “More on Family Security – require password to open family files

  1. 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

    • 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.”

  2. 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.

  3. 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.

  4. 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?

    • 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

  5. 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?

  6. 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…

  7. 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.

  8. 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…

    • 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

      • Hi Harry,
        Is it possible to create a macro that has a function to “not allowed user to disable the macro”. opening project file will failed if user disable the macro?

        Thank you.

        • You can try these new MacroManager methods in 2014:
          SetApplicationMacroSecurityOptions Sets the application macro security options.
          SetDocumentMacroSecurityOptions Sets the document macro security options.

          • Hi Harry,
            I have tried using SetDocumentMacroSecurityOptions to set document macro security to “enable” and it a success. Although I able to do that, users still able to disable the macro using “Macro Security Setting” Options Dialog. Can I control the Option dialog?

            Thank you.

            Abby.

  9. Hi Harry,

    I cant find any solution to prevent user from disable my revit macro. So what I have done is:
    I created an event function that will trigger when revit document is closing.

    void ControlledApplication_DocumentClosing(object sender, Autodesk.Revit.DB.Events.DocumentClosingEventArgs e)
    {
    Document doc = e.Document;
    Autodesk.Revit.DB.Macros.MacroManager.SetDocumentMacroSecurityOptions(doc.Application, Autodesk.Revit.DB.Macros.DocumentMacroOptions.EnableMacros);
    doc.Regenerate();
    throw new NotImplementedException();
    }

    But nothing happened. Is is possible to do this way?

    Thank you.
    Abby.

      • Hi Harry,

        Yes. I did register it on startup.
        i_uiapplication.ControlledApplication.DocumentClosing += new EventHandler(ControlledApplication_DocumentClosing);
        When I set a breakpoint at the line of the code, it stop at that line.

        I’m using doc.Regenerate because I thought SetDocumentMacroSecurityOption need to update the element in the revit document to reflect all changes since it nothing happened when i’m using it before. Unfortunately, the result still same with previously.

        Thank you.
        Abby

  10. We have built a parameter scrambler that encrypts the names of the desired parameters in families, makes them hidden from view in a project and makes them read-only (2015). Several folks have expressed this as a solution for deliverables to other people outside of the firm as it basically renders the content unusable for a pirated need. We call it enigma and it doesn’t require that each person have the add-in.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s