Date:
13 Aug 2009
Category:
Extensions
Discuss:
4 comments

So, some of you would have noticed the Symphony Shell Extension appear today. We're really excited about this as it will open the door to a whole new area of Symphony development. Writing for the command line.

Here's an excerpt from the README:

The Symphony Shell extension is a framework that allows commands to run from the command line. Commands are scripts provided by this and/or other extensions. ...

Developers will be able to include commands in their extensions, allowing for operations not suited to web servers. The command API gives access to Symphony core framework, including Database, Config, Log etc.

The point of this blog entry will be mainly to get the creative juices flowing and get you, the readers, into the headspace. It's actually a little hard to explain how this Extension works so I'll just take it for granted that my explanations in the README and the information below are enough, however feel free to post here or in the forum with further questions.

Imagine, if you will, the following awesomeness.

  1. Export Ensemble, similar to how it functions now, but done via the shell instead. symphony export_ensemble export [args]
  2. Some kind of automated downloading and installation of Extensions. Think package managers like yum or aptitude in Linux. symphony extension-get install akismet
  3. Website index/crawler. This kind of thing is best suited to a shell script as it often needs more resources or time to run than the web server can provide. Not to mention it can tie up the web server effecting your live sites performance. symphony crawler start
  4. Commands for various maintenance like tasks. Possibilities include exporting the database for backup, optimizing tables, repairing file permissions, deleting old logs etc. symphony housekeeping delete-logs -o 2009-08-01 or symphony housekeeping optimise-tables
  5. Invoke commands via another non-symphony related script. For example, tell CRON to run symphony housekeeping optimise-tables every week or incorporate symphony export_ensemble export [args] into a script that pushes the exported code up to a remote server using scp.

These are just a few of the ideas I had whist writing this blog entry.

Another great thing is the ability for Extension developers to ship companion commands for their extensions. E.G. the Maintenance Mode extension might have commands to toggle on/off maintenance mode such as symphony maintenance_mode on and symphony maintenance_mode off in addition to the interface in the Symphony administration area.

As far as coding goes, the barrier of entry is lower since you don't need to worry about admin interfaces and the API used for creating commands is very simple. Extend the ShellCommand class, and create a run() function. That's it. The rest is up to you. Of course you have full access to the Symphony core code, but you can steer away if you wish and write everything yourself. Since these scripts are running at a lower level, you'll also have more direct access to the server.

This leads me to an important question. What about security? There are two fronts here. Firstly, since these files are in public folders, they need to be safe from access via the URL. Secondly, as the scripts might be fairly powerful, it needs to be possible to disallow access to non-authors or non-developers.

The first concern is easily addressed with the use of a .htaccess directive such as deny from all and it is recommended that all developers include this in their <Extension>/bin folder. This will deny all requests that come in via the webserver (HTTP, HTTPS etc.). Also, since the commands have no trailing .php in their name, it is likely to be served up as plain text rather than parsed and compiled.

The second security concern is taken care of by allowing commands direct access to the built in Symphony authentication features. Here is the usage details as displayed via the --usage flag:

usage: symphony [-t token] extension command [OPTIONS]
    runs command provided via extension

options:
    -t  authentication token. Can be enabled via Symphony author 
        profile. Not all extensions require authentication. Check
        individual extension commands for usage.

examples:
    symphony -t 4141e465 shell test

Any command that has the -t option passed will trigger the Symphony core to log the user in and throw an exception should the token be invalid. In addition to this, commands can test whether the user has been logged in, Shell::instance()->isLoggedIn(), and also if they are an author or developer, Shell::instance()->Author->isDeveloper(). Lastly the command files themselves, since being run at a lower level than the webserver, can have stricter permissions placed on them. Permissions that would otherwise cause the webserver to complain.

So that is a quick run down of the new Symphony Shell Extension and what it brings to the table. We're really looking forward to this extension seeing some action from the developers and the creative ways it might get used.

Comments

Very, very cool. In the words of a colleague:

This excites me in inappropriate ways

Could you document how to get a user’s token for authentication? I can get it from the remote-login URL — is there any other way?

is there any other way?

That’s it for now. I am considering allowing something like -u fred -p abc123 which might make it easier.

v0.3 accepts a -u flag now and prompts for the password.

After nearly 7 years I have posted a major update to this extension. Check it out http://www.getsymphony.com/discuss/thread/112143/1/

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details