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.
- Export Ensemble, similar to how it functions now, but done via the shell instead.
symphony export_ensemble export [args]
- Some kind of automated downloading and installation of Extensions. Think package managers like
yum
oraptitude
in Linux.symphony extension-get install akismet
- 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
- 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
orsymphony housekeeping optimise-tables
- Invoke commands via another non-symphony related script. For example, tell CRON to run
symphony housekeeping optimise-tables
every week or incorporatesymphony export_ensemble export [args]
into a script that pushes the exported code up to a remote server usingscp
.
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:
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?
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.