anchor.diff:  
   [source,yaml]
   authentication: {
  -  className: org.apache.tinkerpop.gremlin.server.auth.SimpleAuthenticator
  +  className: org.apache.tinkerpop.gremlin.server.auth.SimpleAuthenticator,
     config: {
       credentialsDb: conf/credential-graph.properties}}
   
  
positive.code: 
  [source,yaml]
  authentication: {
    className: org.apache.tinkerpop.gremlin.server.auth.SimpleAuthenticator
    config: {
      credentialsDb: conf/tinkergraph-empty.properties,
      credentialsDbLocation: data/credentials.kryo}}
  
negative.code: credentials.removeUser("daniel")
  credentials.countUsers()
  ----
  
  [[script-execution]]
  Script Execution
  ++++++++++++++++
  
  It is important to remember that Gremlin Server exposes a `ScriptEngine` instance that allows for remote execution of arbitrary code on the server.  Obviously, this situation can represent a security risk or, more minimally, provide ways for "bad" scripts to be inadvertently executed. A simple example of a "valid" Gremlin script that would cause some problems would be, `while(true) {}`, which would consume a thread in the Gremlin pool indefinitely, thus preventing it from serving other requests.  Sending enough of these kinds of scripts would eventually consume all available threads and Gremlin Server would stop responding.
  
  Gremlin Server (more specifically the `GremlinGroovyScriptEngine`) provides methods to protect itself from these kinds of troublesome scripts.  A user can configure the script engine with different `CompilerCustomizerProvider` implementations.  Consider the basic configuration from the Gremlin Server YAML file:
  
  [source,yaml]
  scriptEngines: {
    gremlin-groovy: {
      imports: [java.lang.Math],
      staticImports: [java.lang.Math.PI],
      scripts: [scripts/empty-sample.groovy]}}
  
  This configuration can be extended to include a `config` key as follows:
  
  [source,yaml]
  scriptEngines: {
    gremlin-groovy: {
      imports: [java.lang.Math],
      staticImports: [java.lang.Math.PI],
      scripts: [scripts/empty-sample.groovy],
      config: {
        compilerCustomizerProviders: {
          "org.apache.tinkerpop.gremlin.groovy.jsr223.customizer.TimedInterruptCustomizerProvider":[10000] }}}
  
  This configuration sets up the script engine with a `CompilerCustomizerProvider` implementation.  The `TimedInterruptCustomizerProvider` injects checks that ensure that loops (like `while`) can only execute for `10000` milliseconds.  With this configuration in place, a remote execution as follows, now times out rather than consuming the thread continuously:
  
  [source,groovy]
  gremlin> :remote connect tinkerpop.server conf/remote.yaml
  ==>Connected - localhost/127.0.0.1:8182
  gremlin> :> while(true) { }
  Execution timed out after 10000 units. Start time: Fri Jul 24 11:04:52 EDT 2015
  
  There are a number of pre-packaged `CustomizerProvider` implementations:
  
  [width="100%",cols="3,10a",options="header"]
  |=========================================================
  |Customizer |Description
  |`CompileStaticCustomizerProvider` |Applies `CompileStatic` annotations to incoming scripts thus removing dynamic dispatch. More information about static compilation can be found in the link:http://docs.groovy-lang.org/latest/html/documentation/#_static_compilation[Groovy Documentation].  It is possible to configure this `CustomizerProvider` by specifying a comma separated list of link:http://docs.groovy-lang.org/latest/html/documentation/#Typecheckingextensions-Workingwithextensions[type checking extensions] that can have the effect of securing calls to various methods.
  |`ThreadInterruptCustomizerProvider` |Injects checks for thread interruption, thus allowing the thread to potentially respect calls to `Thread.interrupt()`
  |`TimedInterruptCustomizerProvider` |Injects checks into loops to interrupt them if they exceed the configured timeout in milliseconds.
  |`TypeCheckedCustomizerProvider` |Similar to the above mentioned, `CompileStaticCustomizerProvider`, the `TypeCheckedCustomizerProvider` injects `TypeChecked` annotations to incoming scripts.  More information on the nature of this annotation can be found in the link:http://docs.groovy-lang.org/latest/html/documentation/#_the_code_typechecked_code_annotation[Groovy Documentation].  It too takes a comma separated list of link:http://docs.groovy-lang.org/latest/html/documentation/#Typecheckingextensions-Workingwithextensions[type checking extensions].
  |=========================================================
  
  To provide some basic out-of-the-box protections against troublesome scripts, the following configuration can be used:
  
  [source,yaml]
  scriptEngines: {
    gremlin-groovy: {
      imports: [java.lang.Math],
      staticImports: [java.lang.Math.PI],
      scripts: [scripts/empty-sample.groovy],
      config: {
        compilerCustomizerProviders: {
          "org.apache.tinkerpop.gremlin.groovy.jsr223.customizer.ThreadInterruptCustomizerProvider":[],
          "org.apache.tinkerpop.gremlin.groovy.jsr223.customizer.TimedInterruptCustomizerProvider":[10000],
          "org.apache.tinkerpop.gremlin.groovy.jsr223.customizer.CompileStaticCustomizerProvider":["org.apache.tinkerpop.gremlin.groovy.jsr223.customizer.SimpleSandboxExtension"]}}}}
  
  NOTE: The above configuration could also use the `TypeCheckedCustomizerProvider` in place of the `CompileStaticCustomizerProvider`.  The differences between `TypeChecked` and `CompileStatic` are beyond the scope of this documentation.  Consult the latest link:http://docs.groovy-lang.org/latest/html/documentation/#_typing[Groovy Documentation' for information on the differences. It is important to understand the impact that these configuration will have on submitted scripts before enabling this feature.
  
  This configuration uses the `SimpleSandboxExtension`, which blacklists calls to methods on the `System` class, thereby preventing someone from remotely killing the server:
  
  [source,groovy]
  ----
  gremlin> :> System.exit(0)
  Script8.groovy: 1: [Static type checking] - Not authorized to call this method: java.lang.System#exit(int)
   @ line 1, column 1.
     System.exit(0)
     ^
  
  1 error
  ----
  
  The `SimpleSandboxExtension` is by no means a "complete" implementation protecting against all manner of nefarious scripts, but it does provide an example for how such a capability might be implemented.  A full implementation would likely represent domain specific white-listing of methods (and possibly variables) available for execution in the script engine.
  
  A final thought on the topic of `CompilerCustomizerProvider` implementations is that they are not just for "security" (though they are demonstrated in that capacity here).  They can be used for a variety of features that can fine tune the Groovy compilation process.  Read more about compilation customization in the link:http://docs.groovy-lang.org/latest/html/documentation/#compilation-customizers[Groovy Documentation].
  
  NOTE: The import of classes to the script engine is handled by the `ImportCustomizerProvider`.  As the concept of "imports" is a first-class citizen (i.e. has its own configuration options), it is not recommended that the `ImportCustomizerProvider` be used as a configuration option to `compilerCustomizerProviders`.
  
  Serialization
  ^^^^^^^^^^^^^
  