CustomAttributes cache per script engine

[ebrandin]

I am trying to use a CustomAttributeLoader to implement API security level and version control, where every user/script may have a different set of available exposed types and methods. As of my understand, this is not quite possible since the cache in CustomAttributes is global and the first executed script will cache the custom attributes. Clearing the cache before every script would add a great performance penalty, and also would not quite work in a multi tenant application.

Currently the only way forward is to add a specific access control method to every exposed method. That would however not be possible if one would want to add security levels to .NET classes/methods.

If a ScriptEngine optionally could contain a local CustomAttributes cache, it would be possible to create pools of engines, differentiated by their capabilities.

Is there another way to solve this use case?

[ClearScriptLib]

Hi @ebrandin,

I am trying to use a CustomAttributeLoader to implement API security level and version control, where every user/script may have a different set of available exposed types and methods.

The title mentions per-engine caching, but here you refer to users and scripts. Can you describe the relationship between users, scripts, and engines in your architecture?

If a ScriptEngine optionally could contain a local CustomAttributes cache, it would be possible to create pools of engines, differentiated by their capabilities.

Per-engine attribute caching seems doable, but it's a departure from standard .NET attribute semantics, which support one static set of attributes per resource. That might be OK, but we'd prefer to explore other options first.

Is there another way to solve this use case?

It seems like you wish to expose your entire API to all clients, and then use attributes to rope off restricted areas. Would it not be possible instead to expose only the portions each client is allowed to access?

Thanks!

[ebrandin]

Is all that that correct?

Yes on all 3 bullet points.

But you aren't asking for ClearScript to support any new attributes, are you?

No, we are note asking for any new attributes. We are not basing our own attributes on ScriptUsageAttribute either, but rather returning a list containing an appropriate ScriptUsageAttribute created by our CustomAttributeLoader depending on whether the entry is allowed or not.

[ClearScriptLib]

A few more questions:

1. Above, you mentioned custom (non-ClearScript) attributes that hold version and capability information. Can you clarify what these attributes would be applied to, and how they'd be used in your scenario?

2. In addition to Clear, what operations on the cache object would be useful?

3. LoadCustomAttributes is invoked in the context of an internal lock. According to the documentation: "This method is performance-critical. Overrides must not invoke script engine methods or other ClearScript functionality." Would that requirement be a problem for your override?

Thanks!

[ebrandin]

1. All API methods and types are in our application tagged with a version, and so is every script. The CustomAttributeLoader will ensure that only the API avaliable for the requested version will be available at runtime. This makes i possible to ensure proper version compatibility of a script.
   Capabilies are used very much like any smart phone app asking for access to certain OS functionality, like camera and contacts. A portion of the API will via our attribute be tagged with such extendend capability. A script that requries such API will need to declare that along with version. The application will require the end user to accept this before running the script.
   A script that fails to declare the correct version or capability should fail at runtime.

2. No methods other than constructor (or creation method) and a setter on the ScriptEngine is required as I see it. I don't even see that Clear is needed if we can attach a cache to a ScriptEngine.

3. The only thing the custom attribute loader does is to find our application specific attributes and compares the version and an optional extended capability with the version and capability specified by the script. There are no external or time consuming operation performed.

[ClearScriptLib]

Thanks. We'll look into this for an upcoming release.

[ebrandin]

Thank you, it would be great if such a feature could make it into the product soon.

[ClearScriptLib]

Hi @ebrandin,

One more question: In your custom attribute loader, how do you intend to determine which engine (or tenant, or application, etc.) is making the request?

Thanks!

[ebrandin]

The plan is to use thread static variables on our custom attribute loader to transfer version and capability information. Would this work or are there situations where the custom attribute loader may be invoked on a different thread than thread invoking ScriptEngine.Execute?

[ClearScriptLib]

Would this work or are there situations where the custom attribute loader may be invoked on a different thread than thread invoking ScriptEngine.Execute?

Methods like Execute are just one way to enter the script engine. Directly calling a script function is another way. Even retrieving a script object property could involve executing a "getter" in script code. As for threads, a script could await a promise bound to a .NET task, and if that task completes on another thread, the script engine could be invoked there as well.

Your custom attribute loader could use ScriptEngine.Current and map the result to the required data. We could add something like ScriptEngine.HostData to facilitate that. Another possibility might be to allow per-engine custom attribute loaders. We're still working out the API details, and we welcome suggestions!