Direct php file access for API endpoint

Silverstripe Version: 4.3


I would like to call a new php file from the root of the project without changing the default rewrite rules file, so I can use it as as API endpoint for a Facebook bot via Botman without Botman Studio (a Laravel installation), bypassing the routing system. I would still, however, want to access the database to perform queries. How could I?

Can you expand a bit more on why you want to bypass the routing system?
It’s fairly trivial to set up a route to a custom controller, and then you’d have full access to all the features of the SilverStripe codebase, including the ORM, etc.

1 Like

Yes, that’s true, but enclosing the code inside a a custom controller, and taking care of all the manipulations, sanitizations and routing of Silverstripe would add a maybe unnecessary complexity layer to my facebook messenger bot app. Also, I think it’s a path I am able to develop if I’m put in a corner.

The decoupled path, on the other hand (bypassing the routing system and sanitization), is for me unclear. That could be a didactic moment, apart from the strategic business decision. I noticed that maybe intentionally for security purposes, the RewriteRules do not check for existance of php files in the root. So I wondered what’s the right course to follow, if one would like to follow that path.

Looking at the docs, Botman can be installed with composer, which means that it will integrate very easily into the SS4 environment. The autoloaders should make everything available within your custom controller.

I think I’d approach it by building a little module which contained the routing and controller, along with the botman dependency. It’s going to be the easiest way to gain access to the SilverStripe functionality.

1 Like

As far as I can understand, a single URL is called as an endpoint from Facebook (if I ignore the other channels, like Slack, Telegram, etc), and the rest of the data is passed via POST. A module would make it very self contained and reusable. Do you think botman be able to access POST variables? I maybe should study Botman Studio, their integrated Laravel installation. That could explain how they did it in a complete framework and steal some ideas.

I haven’t looked at the Botman code in depth, but I would imagine it’s just grabbing the data directly from the request. The docs don’t seem to suggest that you need to pass it any specific data when you set up the listeners.

1 Like

Thanks for answering my questions. I wanted to go the direct PHP route by changing the .htaccess file, but that would make the bot disconnected from the site and not being able to access easily the data contained within the Silverstripe space . An integrated approach would make it better. Just of the sake of knowing, what if I wanted to follow the original plan?

Well, I think you’d either need to access the database directly with native PHP code (something like PDO), which is probably going to be just as time-consuming. Alternatively, you’d need to bootstrap the SilverStripe core functions so you could access them in your script… but if you’re going that far then once again, you’re pretty much back at the point of just using the framework.

1 Like

If you don’t need the integration then you can just add a condition to your htaccess file like

RewriteCond %{REQUEST_URI} !^/FaceBot.php

above the RewriteRule .* index.php.

Then you would need to talk to the database with regular PHP like @Tim said, taking care to sanitise input etc. yourself. You could save yourself a little bit of time though by reading the database credentials from your environment (.env file or environment variables).

One good reason to bypass SilverStripe (if you don’t need it) is you might get a major performance boost. Bootstrapping SilverStripe for a request adds quite a lot of overhead, so if you can cut it out your server should be able to respond to more requests per minute, making it less likely to buckle under pressure.

1 Like

I’ve found out that many commercial bot services are quite slow to answer (even in the seven seconds ballpark), so performance could not be an issue if it answers in usual webpage processing times, or even if it answers within the first two seconds range.

I’ll probably use the rule @JonoM suggested during development, and then add SilverStripe once everything works as expected, right before adding the dynamic parts, so to proceed in a controller as @Tim and repackage as an open source module, with settings in the panel.