<li><aclass="reference internal"href="#built-in-plugins-as-examples"id="id17">Built In Plugins As Examples</a><ul>
<li><aclass="reference internal"href="#built-in-plugins"id="id18">Built In Plugins</a></li>
<li><aclass="reference internal"href="#interceptor-and-repeater"id="id19">Interceptor and Repeater</a></li>
</ul>
</li>
</ul>
</div>
<divclass="section"id="introduction">
<h2><aclass="toc-backref"href="#id1">Introduction</a><aclass="headerlink"href="#introduction"title="Permalink to this headline">¶</a></h2>
<p>Are macros not powerful enough? Want to make something reusable? Want to add console commands?! Then you might want to write yourself a plugin. Some quick highlights about plugins:</p>
<ulclass="simple">
<li>Python scripts stored in <codeclass="docutils literal"><spanclass="pre">~/.pappy/plugins</span></code></li>
<li>Can add console commands</li>
<li>For actions which aren’t specific to one project</li>
<li>Harder to write than macros</li>
</ul>
<p>Since macros can also use the plugin API, plugins aren’t any more powerful than macros (besides adding console commands). However, if you find yourself copying a useful macro to more than one project, it may be worth it to just bind it to some commands, put the script in one place, and stop worrying about copying it around. Plus then you can put it on GitHub for some sweet sweet nerd cred.</p>
<h3><aclass="toc-backref"href="#id2">Should I Write a Plugin or a Macro?</a><aclass="headerlink"href="#should-i-write-a-plugin-or-a-macro"title="Permalink to this headline">¶</a></h3>
<p>A lot of the time, you can get away with writing a macro. However, you may consider writing a plugin if:</p>
<ulclass="simple">
<li>You find yourself copying one macro to multiple projects</li>
<li>You want to write a general tool that can be applied to any website</li>
<li>You need to maintain state during the Pappy session</li>
</ul>
<p>My guess is that if you need one quick thing for a project, you’re better off writing a macro first and seeing if you end up using it in future projects. Then if you find yourself needing it a lot, write a plugin for it. You may also consider keeping a <codeclass="docutils literal"><spanclass="pre">mine.py</span></code> plugin where you can write out commands that you use regularly but may not be worth creating a dedicated plugin for.</p>
</div>
<divclass="section"id="plugins-get-merged">
<h3><aclass="toc-backref"href="#id3">Plugins Get Merged</a><aclass="headerlink"href="#plugins-get-merged"title="Permalink to this headline">¶</a></h3>
<p>If you write a useful plugin, as long as it isn’t uber niche, I’ll try and merge it into the core project.</p>
</div>
</div>
<divclass="section"id="creating-a-plugin">
<h2><aclass="toc-backref"href="#id4">Creating a Plugin</a><aclass="headerlink"href="#creating-a-plugin"title="Permalink to this headline">¶</a></h2>
<p>Whenever you make a macro, you’ll have to bind some functions to some console commands. To do this, you’ll have to define a <codeclass="docutils literal"><spanclass="pre">load_cmds</span></code> function in your plugin. This function should take one argument. When the plugin is loaded, this function will be called and the console object will be passed to this function. You can then use <codeclass="docutils literal"><spanclass="pre">set_cmds</span></code> and <codeclass="docutils literal"><spanclass="pre">add_aliases</span></code> to bind functions to console commands.</p>
<h3><aclass="toc-backref"href="#id5">Writing a Hello World Plugin</a><aclass="headerlink"href="#writing-a-hello-world-plugin"title="Permalink to this headline">¶</a></h3>
<p>It’s probably easiest to explain how to write a plugin by writing one. Here is a simple plugin that defines a <codeclass="docutils literal"><spanclass="pre">hello</span></code> command and gives an alias <codeclass="docutils literal"><spanclass="pre">hlo</span></code> (we’ll go over all the parts in a second):</p>
<p>Save this as <codeclass="docutils literal"><spanclass="pre">~/.pappy/plugins/hello.py</span></code> and run Pappy. You should have a new <codeclass="docutils literal"><spanclass="pre">hello</span></code> command that prints your message:</p>
<p>Awesome! So let’s go over the code. Here are the important parts of the code:</p>
<ulclass="simple">
<li>We define a function that we want to call</li>
<li>We define <codeclass="docutils literal"><spanclass="pre">load_cmds(cmd)</span></code> to be called when our plugin is loaded to bind our function to a command</li>
<li>We use <codeclass="docutils literal"><spanclass="pre">cmd.set_cmds</span></code> to set all our commands</li>
<li>We use <codeclass="docutils literal"><spanclass="pre">cmd.add_aliases</span></code> to add aliases for commands</li>
<h3><aclass="toc-backref"href="#id6">Passing Arguments to Your Function</a><aclass="headerlink"href="#passing-arguments-to-your-function"title="Permalink to this headline">¶</a></h3>
<p>Each command gets bound to one function which takes one argument. That argument is all the text that was entered after the name of the command in the console. For example if we run <codeclass="docutils literal"><spanclass="pre">hello</span><spanclass="pre">foo</span><spanclass="pre">bar</span></code>, in our function line would be “foo bar”. <strong>I suggest using shlex.split(line) to parse multiple arguments</strong>. So let’s update our script to take some arguments:</p>
<h3><aclass="toc-backref"href="#id7">Adding More Aliases</a><aclass="headerlink"href="#adding-more-aliases"title="Permalink to this headline">¶</a></h3>
<p>So now let’s add some more aliases to our command. If we want to add a new alias, we just add another tuple to the list passed into <codeclass="docutils literal"><spanclass="pre">cmd.add_aliases</span></code>. The first element is the real name of the command (what you set with <codeclass="docutils literal"><spanclass="pre">set_cmds</span></code>) and the second value is the alias you want to type. So let’s make it so we can just type <codeclass="docutils literal"><spanclass="pre">ho</span></code> to say hello:</p>
<pclass="last">You must use the actual name of the command that you used in <codeclass="docutils literal"><spanclass="pre">set_cmds</span></code>. You can’t “chain” alieases. As a result, in our example we couldn’t add the alias <codeclass="docutils literal"><spanclass="pre">('hlo',</span><spanclass="pre">'ho')</span></code> to add <codeclass="docutils literal"><spanclass="pre">ho</span></code> as our alias.</p>
<h3><aclass="toc-backref"href="#id8">Adding Another Command</a><aclass="headerlink"href="#adding-another-command"title="Permalink to this headline">¶</a></h3>
<p>So now let’s add a <codeclass="docutils literal"><spanclass="pre">robe_and_wizard_hat</span></code> command. To do this, we will define another function, then add another entry in the dict that is passed to <codeclass="docutils literal"><spanclass="pre">set_cmds</span></code>. The second value in the tuple is the autocomplete function, but we’ll get to that later. For now, just put in <codeclass="docutils literal"><spanclass="pre">None</span></code> to say we don’t have one. We will also add a <codeclass="docutils literal"><spanclass="pre">wh</span></code> alias to it:</p>
<h3><aclass="toc-backref"href="#id9">Adding Autocompletion</a><aclass="headerlink"href="#adding-autocompletion"title="Permalink to this headline">¶</a></h3>
<p>You can also define a function to handle autocompletion for your command. In order to do this, you define a function that takes 4 arguments: <codeclass="docutils literal"><spanclass="pre">text</span></code>, <codeclass="docutils literal"><spanclass="pre">line</span></code>, <codeclass="docutils literal"><spanclass="pre">begidx</span></code>, and <codeclass="docutils literal"><spanclass="pre">endidx</span></code>. From the <aclass="reference external"href="https://docs.python.org/2/library/cmd.html">Cmd docs</a>, this is what the arguments mean:</p>
<blockquote>
<div><codeclass="docutils literal"><spanclass="pre">text</span></code> is the string prefix we are attempting to match: all returned matches must begin with it. <codeclass="docutils literal"><spanclass="pre">line</span></code> is the current input line with leading whitespace removed, <codeclass="docutils literal"><spanclass="pre">begidx</span></code> and <codeclass="docutils literal"><spanclass="pre">endidx</span></code> are the beginning and ending indexes of the prefix text, which could be used to provide different completion depending upon which position the argument is in.</div></blockquote>
<p>Let’s let the user to autocomplete some names in our plugin:</p>
<spanclass="k">print</span><spanclass="s1">'</span><spanclass="si">%s</span><spanclass="s1"> puts on their robe and wizard hat'</span><spanclass="o">%</span><spanclass="n">line</span>
<p>You can’t see it, but I hit tab twice after typing hello to get the completions to appear.</p>
</div>
<divclass="section"id="adding-help">
<h3><aclass="toc-backref"href="#id10">Adding Help</a><aclass="headerlink"href="#adding-help"title="Permalink to this headline">¶</a></h3>
<p>Now let’s say we want to add some help to the command so that when the user runs <codeclass="docutils literal"><spanclass="pre">help</span><spanclass="pre">hello</span></code> they get something useful. To do that, just add a docstring to your function:</p>
<spanclass="k">print</span><spanclass="s1">'</span><spanclass="si">%s</span><spanclass="s1"> puts on their robe and wizard hat'</span><spanclass="o">%</span><spanclass="n">line</span>
<h3><aclass="toc-backref"href="#id11">Using defer.inlineCallbacks With a Command</a><aclass="headerlink"href="#using-defer-inlinecallbacks-with-a-command"title="Permalink to this headline">¶</a></h3>
<divclass="admonition note">
<pclass="first admonition-title">Note</p>
<pclass="last">If you are using inlineCallbacks, you can’t use any functions which are blocking versions of async functions. For example, you cannot use <aclass="reference internal"href="pappyproxy.html#pappyproxy.http.Request.save"title="pappyproxy.http.Request.save"><codeclass="xref py py-func docutils literal"><spanclass="pre">pappyproxy.http.Request.save()</span></code></a> and must instead use <aclass="reference internal"href="pappyproxy.html#pappyproxy.http.Request.async_deep_save"title="pappyproxy.http.Request.async_deep_save"><codeclass="xref py py-func docutils literal"><spanclass="pre">pappyproxy.http.Request.async_deep_save()</span></code></a>.</p>
</div>
<divclass="admonition note">
<pclass="first admonition-title">Note</p>
<pclass="last">This tutorial won’t tell you how to use inlineCallbacks in general. Type “twisted inline callbacks” into google to figure out what they are. This is mainly just a reminder to use the <codeclass="docutils literal"><spanclass="pre">crochet</span></code> wrapper for console commands and warning you that some functions may return deferreds that you may have to deal with.</p>
<p>Since you’re writing a plugin, you’ll probably be using functions which return a deferred. And to keep things readable, you’ll want to use the <codeclass="docutils literal"><spanclass="pre">defer.inlineCallbacks</span></code> function wrapper. Unfortunately, you can’t bind async functions to commands. Luckily, there’s a library called <aclass="reference external"href="https://pypi.python.org/pypi/crochet">crochet</a> which lets you add another wrapper to the function that lets it be used like a blocking function. Rather than talking about it, let’s write a plugin to call <aclass="reference internal"href="pappyproxy.html#pappyproxy.util.load_reqlist"title="pappyproxy.util.load_reqlist"><codeclass="xref py py-func docutils literal"><spanclass="pre">pappyproxy.util.load_reqlist()</span></code></a> to print out some requests’ hosts. Let’s start by pretending it’s a normal function:</p>
<spanclass="n">reqs</span><spanclass="o">=</span><spanclass="n">load_reqlist</span><spanclass="p">(</span><spanclass="n">args</span><spanclass="p">[</span><spanclass="mi">0</span><spanclass="p">])</span><spanclass="c1"># It's supposed to return a list of requests, right?</span>
<spanclass="k">print</span><spanclass="s1">'The host for request </span><spanclass="si">%s</span><spanclass="s1"> is: </span><spanclass="si">%s</span><spanclass="s1">'</span><spanclass="o">%</span><spanclass="p">(</span><spanclass="n">r</span><spanclass="o">.</span><spanclass="n">reqid</span><spanclass="p">,</span><spanclass="n">r</span><spanclass="o">.</span><spanclass="n">host</span><spanclass="p">)</span>
<p>Iteration over a non-sequence? what? Well, <aclass="reference internal"href="pappyproxy.html#pappyproxy.util.load_reqlist"title="pappyproxy.util.load_reqlist"><codeclass="xref py py-func docutils literal"><spanclass="pre">pappyproxy.util.load_reqlist()</span></code></a> doesn’t actually return a list of requests. It returns a deferred which returns a list of requests. I’m not going into the details (look up some stuff on using inline callbacks with Twisted if you want more info), but the way to fix it is to slap an <codeclass="docutils literal"><spanclass="pre">inlineCallbacks</span></code> wrapper on the function and <codeclass="docutils literal"><spanclass="pre">yield</span></code> the result of the function. Now it looks like this:</p>
<spanclass="k">print</span><spanclass="s1">'The host for request </span><spanclass="si">%s</span><spanclass="s1"> is: </span><spanclass="si">%s</span><spanclass="s1">'</span><spanclass="o">%</span><spanclass="p">(</span><spanclass="n">r</span><spanclass="o">.</span><spanclass="n">reqid</span><spanclass="p">,</span><spanclass="n">r</span><spanclass="o">.</span><spanclass="n">host</span><spanclass="p">)</span>
<p>However, the console assumes that any functions it calls will be blocking. As a result, we need to add the <codeclass="docutils literal"><spanclass="pre">crochet.wait_for</span></code> wrapper:</p>
<spanclass="k">print</span><spanclass="s1">'The host for request </span><spanclass="si">%s</span><spanclass="s1"> is: </span><spanclass="si">%s</span><spanclass="s1">'</span><spanclass="o">%</span><spanclass="p">(</span><spanclass="n">r</span><spanclass="o">.</span><spanclass="n">reqid</span><spanclass="p">,</span><spanclass="n">r</span><spanclass="o">.</span><spanclass="n">host</span><spanclass="p">)</span>
<p>And now we’re good! If you run it without the crochet wrapper, it may still work. However, since the console assumes any functions it calls will be blocking, not having the wrapper could lead to weird errors.</p>
</div>
</div>
<divclass="section"id="plugin-api">
<h2><aclass="toc-backref"href="#id12">Plugin API</a><aclass="headerlink"href="#plugin-api"title="Permalink to this headline">¶</a></h2>
<p>There are also some useful functions that you can use to interact with the request history and the context. It’s somewhat limited for now, but for now you can at least look through history and create/send new requests. Hopefully the API will expand as people find themselves wanting to do new things. That means <strong>if you’re writing a plugin, let me know and I’ll add any APIs you need</strong>. For now at least, plugins will let you maintain state over the course of the session and let you define commands.</p>
<p>The best way to learn what you can do is to go through the <spanclass="xref std std-ref">pappyproxy-package</span> and look at all the available functions.</p>
<divclass="section"id="api-functions">
<h3><aclass="toc-backref"href="#id13">API Functions</a><aclass="headerlink"href="#api-functions"title="Permalink to this headline">¶</a></h3>
<p>See <aclass="reference internal"href="pappyproxy.html#module-pappyproxy.plugin"title="pappyproxy.plugin"><codeclass="xref py py-mod docutils literal"><spanclass="pre">pappyproxy.plugin</span></code></a> for docs on all the functions you can use. You can also use any of the functions provided for writing macros (and vice-versa).</p>
</div>
<divclass="section"id="storing-data-on-disk">
<h3><aclass="toc-backref"href="#id14">Storing Data on Disk</a><aclass="headerlink"href="#storing-data-on-disk"title="Permalink to this headline">¶</a></h3>
<p>Unfortunately, you’re on your own if you want to store plugin specific stuff on disk. It’s also important that you store any data that is specific to a project in the same directory as the data file. This is to make sure that if you encrypt your project folder, you can be sure that no sensitive data about the test can be found anywhere else. The only time you should store anything outside of the current directory is to store global plugin settings, and even then it would probably be better to parse options from <codeclass="docutils literal"><spanclass="pre">config.config_dict</span></code>. Pappy doesn’t even store data outside of the project directory except for its CA certificates.</p>
<p>However, if your plugin is a special snowflake that needs to store unencrypted, global settings, you should create a directory for your plugin in <codeclass="docutils literal"><spanclass="pre">{config.DATA_DIR}/plugindata</span></code> and put your files there. But again, avoid this if you can.</p>
<divclass="admonition note">
<pclass="first admonition-title">Note</p>
<pclass="last">Any project-specific data (ie anything that contains info about requests) should be stored in the project directory unless you have a really really good reason. This is because it must be possible to secure any sensitive data by encrypting the project folder and storing data outside of the directory will add complications.</p>
</div>
<divclass="admonition warning">
<pclass="first admonition-title">Warning</p>
<pclass="last">Do not modify the data file schema. There is a good chance the schema will break in future versions of Pappy.</p>
<h3><aclass="toc-backref"href="#id15">Storing Custom Request Metadata</a><aclass="headerlink"href="#storing-custom-request-metadata"title="Permalink to this headline">¶</a></h3>
<p><aclass="reference internal"href="pappyproxy.html#pappyproxy.http.Request"title="pappyproxy.http.Request"><codeclass="xref py py-class docutils literal"><spanclass="pre">pappyproxy.http.Request</span></code></a> objects have a <codeclass="docutils literal"><spanclass="pre">plugin_data</span></code> attribute. It is a dictionary that is intended to be used by plugins to give the request custom metadata. If you want to store metadata about a request, it is suggested that you add a key to this dictionary and store any metadata you want under that key. You can use <aclass="reference internal"href="pappyproxy.html#pappyproxy.http.Request.get_plugin_dict"title="pappyproxy.http.Request.get_plugin_dict"><codeclass="xref py py-func docutils literal"><spanclass="pre">pappyproxy.http.Request.get_plugin_dict()</span></code></a> to get a dictionary for a specific name. It will create an entry for that name if it doesn’t exist. I also suggest defining a function plugin-wide for getting the plugin’s data dict from a specific request. Since dictionaries are always passed by reference, any modifications you make to the returned dict will be applied to the request as well.</p>
<pclass="last">You will need to save the request using something like <aclass="reference internal"href="pappyproxy.html#pappyproxy.http.Request.save"title="pappyproxy.http.Request.save"><codeclass="xref py py-func docutils literal"><spanclass="pre">pappyproxy.http.Request.save()</span></code></a> or <aclass="reference internal"href="pappyproxy.html#pappyproxy.http.Request.async_deep_save"title="pappyproxy.http.Request.async_deep_save"><codeclass="xref py py-func docutils literal"><spanclass="pre">pappyproxy.http.Request.async_deep_save()</span></code></a> in order to store the changes in the data file.</p>
</div>
<p>Here is an example plugin for storing the user-agent (if it exists) in the <codeclass="docutils literal"><spanclass="pre">plugin_data</span></code> dict of a request under the key <codeclass="docutils literal"><spanclass="pre">agent</span></code>:</p>
<spanclass="k">print</span><spanclass="s1">'The user agent for </span><spanclass="si">%s</span><spanclass="s1"> is "</span><spanclass="si">%s</span><spanclass="s1">"'</span><spanclass="o">%</span><spanclass="p">(</span><spanclass="n">r</span><spanclass="o">.</span><spanclass="n">reqid</span><spanclass="p">,</span><spanclass="n">get_data</span><spanclass="p">(</span><spanclass="n">r</span><spanclass="p">)[</span><spanclass="s1">'agent'</span><spanclass="p">])</span>
<spanclass="k">print</span><spanclass="s1">'Request </span><spanclass="si">%s</span><spanclass="s1"> has no user agent data'</span><spanclass="o">%</span><spanclass="n">r</span><spanclass="o">.</span><spanclass="n">reqid</span>
<h2><aclass="toc-backref"href="#id17">Built In Plugins As Examples</a><aclass="headerlink"href="#built-in-plugins-as-examples"title="Permalink to this headline">¶</a></h2>
<divclass="section"id="built-in-plugins">
<h3><aclass="toc-backref"href="#id18">Built In Plugins</a><aclass="headerlink"href="#built-in-plugins"title="Permalink to this headline">¶</a></h3>
<p>All the commands in Pappy are implemented as plugins. I have done what I could to avoid using internal functions as much as I could, but there are still some instances where I had to implement an internal function in order to get the functions I needed. However, you can still look them over to see how things are structured and see some examples of semi-complicated plugins.</p>
</div>
<divclass="section"id="interceptor-and-repeater">
<h3><aclass="toc-backref"href="#id19">Interceptor and Repeater</a><aclass="headerlink"href="#interceptor-and-repeater"title="Permalink to this headline">¶</a></h3>
<p>Pappy’s interceptor and repeater are fully implemented as a plugin. It defines an intercepting macro that handles saving then editing messages and commands that read those files and edit them. It relies on Twisted to switch between the macro handling the request and the command modifying it, so if you want to make something similar, you’ll have to learn how to use deferreds.</p>
