How to get wercker environment vars from php? - php

I'm currently writing unit tests for an API written in PHP. This API implements a RateLimiting step before each request, and I want to avoid this step while I'm testing the application.
Now, if I want to run the tests locally I just have to check the local IP, which is "::1". But I'm having problems accessing the environment variables that my continuous integration server provides (I am using wercker).
If I run this from a PHPUnit test:
var_export(isset($_SERVER["CI"]) || isset($_SERVER["wercker"]));
I get true, but if I do do something similar before applying the rate limiting:
if (isset($_SERVER["CI"]) || $request->getIp() === "::1") {
return;
} else {//...
the wercker tests keep failing because it never skips the rate limiting logic. Notice that the first piece of code is run from a test in PHPUnit, while the second one is part of the server application.
What am I doing wrong with the environment variables?
Please let me know if I must provide more information or documentation.

I was able to make it work by using PHP's getenv function
if (getenv("CI") || $request->getIp() === "::1") {
return;
} else {//...

To display all environment variables on Wercker server, add this step (E.g : in build section) :
build:
steps:
- script:
name: show env vars
code: env

Related

Environment variables contain wrong values in jobs

When I try to access an environment variable in a job (queue is database), I get an incorrect value.
I am trying to retrieve the APP_DEBUG variable because during development a Windows program is to be used for execution, while in the production system a Linux binary is used.
I have already restarted the queue, worked with queue:listen, and cleared the cache.
I assume that the .env is not read by the queue.
What options do I have to work around this behavior?
Or is there a solution for the problem?
Here is a sample of my code
/**
* Execute the index job.
*/
public function handle()
{
// Some code ...
if (true == env('APP_DEBUG')) {
WindowsFileIndexer::dispatchNow();
} else {
LinuxFileIndexer::dispatchNow();
}
// Some more job calls ...
}
Of course I know that I could get to the operating system via other ways (PHP_OS, etc.) and thus also check it. However, it must be possible to use the environment variables in a job.

How can I do a partial integration test (phpunit)?

I am working on an extension (app) of nextcloud (which is based on Symfony). I have a helper class to extract data from the request that is passed by the HTTP server to PHP. A much-reduced one could be something like this (to get the point here):
<?php
namespace OCA\Cookbook\Helpers;
class RequestHelper {
public function getJson(){
if($_SERVER['Request_Method' === 'PUT'){ // Notice the typos, should be REQUEST_METHOD
$raw = file_get_content('php://input');
return json_decode($raw, true);
} else { /* ... */ }
}
}
Now I want to test this code. Of course, I can do some unit testing and mock the $_SERVER variable. Potentially I would have to extarct the file_get_content into its own method and do a partial mock of that class. I get that. The question is: How much is this test worth?
If I just mimick the behavior of that class (white box testing) in my test cases I might even copy and paste the typo I intentionally included here. As this code is an MWE, real code might get more complex and should be compatible with different HTTP servers (like apache, nginx, lighttpd etc).
So, ideally, I would like to do some automated testing in my CI process that uses a real HTTP server with different versions/programs to see if the integration is working correctly. Welcome to integration testing.
I could now run the nextcloud server with my extension included in a test environment and test some real API endpoints. This is more like functional testing as everything is tested (server, NC core, my code and the DB):
phpunit <---> HTTP server <---> nextcloud core <---> extension code <---> DB
^
|
+--> RequestHelper
Apart from speed, I have to carefully take into account to test all possible paths through the class RequestHelper (device under test, DUT). This seems a bit brittle to me in the long run.
All I could think of is adding a simple endpoint only for testing the functionality of the DUT, something like a pure echo endpoint or so. For the production use, I do not feel comfortable having something like this laying around.
I am therefore looking for an integration test with a partial mock of the app (mocking the business logic + DB) to test the route between the HTTP server and my DUT. In other words, I want to test the integration of the HTTP server, nextcloud core, my controller, and the DUT above without any business logic of my app.
How can I realize such test cases?
Edit 1
As I found from the comments the problem statement was not so obviously clear, I try to explain a bit at the cost of the simplicity of the use-case.
There is the nextcloud core that can be seen as a framework from the perspective of the app. So, there can be controller classes that can be used as targets for URL/API endpoints. So for example /apps/cookbook/recipe/15 with a GET method will fetch the recipe with id 15. Similarly, with PUT there can be a JSON uploaded to update that recipe.
So, inside the corresponding controller the structure is like
class RecipeController extends Controller {
/* Here the PUT /apps/cookbook/recipe/{id} endpoint will be routed */
public function update($id){
$json = $this->requestHelper->getJson(); // Call to helper
// Here comes the business logic
// aka calls to other classes that will save and update the state
// and perform the DB operation
$this->service->doSomething($json);
// Return an answer if the operation terminated successfully
return JsonResponse(['state'=>'ok'], 200);
}
}
I want to test the getJson() method against different servers. Here I want to mock at least the $this->service->doSomething($json) to be a no-op. Ideally, I would like to spy into the resulting $json variable to test that exactly.
No doubt, in my test class it would be something like
class TestResponseHandler extends TestCase {
public function setUp() { /* Set up the http deamon as system service */}
public testGetJson() {
// Creat Guzzle client
$client = new Client([
'base_uri' => 'http://localhost:8080/apps/cookbook',
]);
// Run the API call
$headers = ...;
$body = ...;
$response = $client->put('recipe/15', 'PUT', $headers, $body);
// Check the response body
// ....
}
}
Now, I have two code interpreters running: Once, there is the one (A) that runs phpunit (and makes the HTTP request). Second, there is the one (B) associated with the HTTP server listening on localhost:8080.
As the code above with the call to getJson() is running inside a PHP interpreter (B) outside the phpunit instance I cannot mock directly as far as I understand. I would have to change the main app's code if I am not mistaken.
Of course, I could provide (more or less) useful data in the test function and let the service->doSomething() method do its job but then I am no longer testing only a subset of functions but I am doing functional or system testing. Also, this makes it harder to generate well-aimed test cases if all these side-effects need to be taken into account.

Codeception functional test example fails on an actual application

Codeception has documentation for functional tests at: https://codeception.com/docs/05-UnitTests
So following that on my laravel/homestead project I do as follows:
in functional.sute.yml:
class_name: FunctionalTester
modules:
enabled:
- Laravel5
- \Helper\Functional
My test:
<?php
class LoginCest
{
public function _before(FunctionalTester $I)
{
}
public function _after(FunctionalTester $I)
{
}
// tests
public function tryLogin (FunctionalTester $I)
{
$I->amOnPage('/login');
$I->fillField('email', 'someemail');
$I->fillField('password', 'somepw');
$I->click('Login');
$
I->see('some text');
}
}
So when I run the test, it fails:
There was 1 error:
---------
1) LoginCest: Try login
Test tests/functional/LoginCest.php:tryLogin
[ExternalUrlException] Codeception\Module\Laravel5 can't open external URL: http://myapp.test/login
Scenario Steps:
4. $I->click("Login") at tests/functional/LoginCest.php:20
3. $I->fillField("password","somepw") at tests/functional/LoginCest.php:19
2. $I->fillField("email","someemail") at tests/functional/LoginCest.php:18
1. $I->amOnPage("/login") at tests/functional/LoginCest.php:17
#1 Codeception\Lib\InnerBrowser->click
#2 /home/vagrant/Code/my-app/tests/_support/_generated/FunctionalTesterActions.php:1114
#3 /home/vagrant/Code/my-app/tests/functional/LoginCest.php:20
#4 LoginCest->tryLogin
ERRORS!
Tests: 1, Assertions: 0, Errors: 1.
My app url is someapp.test which is running on homestead.
In looking at my LoginController I see:
$this->redirectTo();
at the very end.
Now I understand that functional tests do not require a webserver and I could probably make it work using the acceptance test. But really having a hard time understanding on why anyone would use codeception to do functional tests if you cant even specify a url. Also why would codeception use a login example for functional test when others may face similar issues?
Some background first.
URL consists of these main parts: PROTOCOL://DOMAIN:PORT/URI?QUERY_STRING#HASH
HASH is only used in client side and not passed to webserver, so it can't be used for routing.
PROTOCOL and PORT can be used for routing, but that is very unusual.
Some websites display different contents depending on DOMAIN which is used to access them,
but most only use URI and/or QUERY_STRING parts for routing and displaying the right page.
The main distinction of functional testing using Codeception is that it doesn't require webserver and because of that mostly doesn't care about domain names.
Website code usually doesn't care if it is accessed using http://myapp.test/ or http://google.com/ and happily returns your front page for either.
Though if a click on http://google.com/ link rendered your front page it almost certainly would be wrong.
To prevent that, external domain check was implemented years ago.
All internal links in your website must have no domain component or it must match the one passed using Host header.
Exception is made for domains that are using for domain based routing, such domains can be used in tests.

How do I test whether running from CakePHP Console?

I have a CakePHP Console Shell that works fine until a Model->afterFind() tries to add some data to the results which includes adding links, which doesn't seem to work while being called from the Console.
Is there a way to test in the Model->afterFind() callback function whether it's being called from a Console Shell, so that I can skip the troublesome section that I don't need anyway?
Thanks,
Ian
I'm not too sure whether there's a Cake way to do it, but you can do it via regular PHP
if(php_sapi_name() == 'cli' && empty(getClientIP())) {
//running via CLI
} else {
//running normally
}
It seems to me that you're breaking MVC best-practices if your business (model) layer is having adverse effects when run in different contexts. Whatever you're putting into Model->afterFind() should be completely agnostic to how the application is executed.
With that understood, the model layer of CakePHP is not at all aware of the execution context. One solution would be to deal with this by passing a flag to the model layer from the shell. ie:
At the top of app_model.php:
var $isShellContext = false;
Then, in your shell:
$this->Model->isShellContext = true;
And then in Model->afterFind():
if(!$this->isShellContext) {
// add links, etc
}

Create cronjob with Zend Framework

I am trying to write a cronjob controller, so I can call one website and have all modules cronjob.php executed. Now my problem is how do I do that?
Would curl be an option, so I also can count the errors and successes?
[Update]
I guess I have not explained it enough.
What I want to do is have one file which I can call like from http://server/cronjob and then make it execute every /application/modules/*/controller/CronjobController.php or have another way of doing it so all the cronjobs aren't at one place but at the same place the module is located. This would offer me the advantage, that if a module does not exist it does not try to run its cronjob.
Now my question is how would you execute all the modules CronjobController or would you do it a completly different way so it still stays modular?
And I want to be able to giveout how many cronjobs ran successfully and how many didn't
After some research and a lot procrastination I came to the simple conclusion that a ZF-ized cron script should contain all the functionality of you zend framework app - without all the view stuff. I accomplished this by creating a new cronjobfoo.php file in my application directory. Then I took the bare minimum from:
-my front controller (index.php)
-my bootstrap.php
I took out all the view stuff and focused on keeping the environment setup, db setup, autoloader, & registry setup. I had to take a little time to correct the document root variable and remove some of the OO functionality copied from my bootstrap.
After that I just coded away.. in my case it was compiling and emailing out nightly reports. It was great to use Zend_Mail. When I was confident that my script was working the way I wanted, I just added it my crontab.
good luck!
For Zend Framework I am currently using the code outlined bellow. The script only includes the portal file index.php, where all the paths, environment and other Zendy code is bootstrapped. By defining a constant in the cron script we cancel the final step , where the application is run.
This means the application is only setup, not even bootstrapped. At this point we start bootstraping the resources we need and that is that
//public/index.php
if(!defined('DONT_RUN_APP') || DONT_RUN_APP == false) {
$application->bootstrap()->run();
}
// application/../cron/cronjob.php
define("DONT_RUN_APP",true);
require(realpath('/srv/www/project/public/index.php'));
$application->bootstrap('config');
$application->bootstrap('db');
//cron code follows
I would caution putting your cronjobs accessible to the public because they could be triggered outside their normal times and, depending on what they do, cause problems (I know that is not what you intend, but by putting them into an actual controller it becomes reachable from the browser). For example, I have one cron that sends e-mails. I would be spammed constantly if someone found the cron URL and just began hitting it.
What I did was make a cron folder and in there created a heartbeat.php which bootstraps Zend Framework (minus MVC) for me. It checks a database which has a list of all the installed cron jobs and, if it is time for them to run, generates an instances of the cron job's class and runs it.
The cron jobs are just child classes from an abstract cron class that has methods like install(), run(), deactivate(), etc.
To fire off my job I just have a simple crontab entry that runs every 5 minutes that hits heartbeat.php. So far it's worked wonderful on two different sites.
Someone mentioned this blog entry a couple days ago on fw-general (a mailinglist which I recommend reading when you use the Zend Framework).
There is also a proposal for Zend_Controller_Request_Cli, which should address this sooner or later.
I have access to a dedicated server and I initially had a different bootstrap for the cron jobs. I eventually hated the idea, just wishing I could do this within the existing MVC setup and not have to bother about moving things around.
I created a file cron.sh, saved is within my site root (not public) and in it I put a series of commands I would like to run. As I wanted to run many commands at once I wrote the PHP within my controllers as usual and added curl calls to those urls within cron.sh. for example curl http://www.mysite.com/cron_controller/action Then on the cron interface I ran bash /path/to/cron.sh.
As pointed out by others your crons can be fired by anyone who guesses the url so there's always that caveat. You can find a solution to that in many different ways.
Take a look at zf-cli:
scripts at master from padraic/ZFPlanet - GitHub
This handles well all cron jobs.
Why not just create a crontab.php, including, or requiring the index.php bootstrap file?
Considering that the bootstrap is executing Zend_Loader::registerAutoload(), you can start working directly with the modules, for instance, myModules_MyClass::doSomething();
That way you are skipping the controllers. The Controller job is to control the access via http. In this case, you don't need the controller approach because you are accessing locally.
Do you have filesystem access to the modules' directories? You could iterate over the directories and determine where a CronjobController.php is available. Then you could either use Zend_Http_Client to access the controller via HTTP or use an approach like Zend_Test_PHPUnit: simulate the actual dispatch process locally.
You could set up a database table to hold references to the cronjob scripts (in your modules), then use a exec command with a return value on pass/fail.
I extended gregor answer with this post. This is what came out:
//public/index.php
// Run application, only if not started from command line (cli)
if (php_sapi_name() != 'cli' || !empty($_SERVER['REMOTE_ADDR'])) {
$application->run();
}
Thanks gregor!
My solution:
curl /cron
Global cron method will include_once all controllers
Check whether each of the controllors has ->cron method
If they have, run those.
Public cron url (for curl) is not a problem, there are many ways to avoid abuse. As said, checking remote IP is the easiest.
This is my way to run Cron Jobs with Zend Framework
In Bootstrap I will keep environment setup as it is minus MVC:
public static function setupEnvironment()
{
...
self::setupFrontController();
self::setupDatabase();
self::setupRoutes();
...
if (PHP_SAPI !== 'cli') {
self::setupView();
self::setupDbCaches();
}
...
}
Also in Bootstrap, I will modify setupRoutes and add a custom route:
public function setupRoutes()
{
...
if (PHP_SAPI == 'cli') {
self::$frontController->setRouter(new App_Router_Cli());
self::$frontController->setRequest(new Zend_Controller_Request_Http());
}
}
App_Router_Cli is a new router type which determines the controller, action, and optional parameters based on this type of request: script.php controller=mail action=send. I found this new router here: Setting up Cron with Zend Framework 1.11
:
class App_Router_Cli extends Zend_Controller_Router_Abstract
{
public function route (Zend_Controller_Request_Abstract $dispatcher)
{
$getopt = new Zend_Console_Getopt (array());
$arguments = $getopt->getRemainingArgs();
$controller = "";
$action = "";
$params = array();
if ($arguments) {
foreach($arguments as $index => $command) {
$details = explode("=", $command);
if($details[0] == "controller") {
$controller = $details[1];
} else if($details[0] == "action") {
$action = $details[1];
} else {
$params[$details[0]] = $details[1];
}
}
if($action == "" || $controller == "") {
die("Missing Controller and Action Arguments == You should have:
php script.php controller=[controllername] action=[action]");
}
$dispatcher->setControllerName($controller);
$dispatcher->setActionName($action);
$dispatcher->setParams($params);
return $dispatcher;
}
echo "Invalid command.\n", exit;
echo "No command given.\n", exit;
}
public function assemble ($userParams, $name = null, $reset = false, $encode = true)
{
throw new Exception("Assemble isnt implemented ", print_r($userParams, true));
}
}
In CronController I do a simple check:
public function sendEmailCliAction()
{
if (PHP_SAPI != 'cli' || !empty($_SERVER['REMOTE_ADDR'])) {
echo "Program cannot be run manually\n";
exit(1);
}
// Each email sent has its status set to 0;
Crontab runs a command of this kind:
* * * * * php /var/www/projectname/public/index.php controller=name action=send-email-cli >> /var/www/projectname/application/data/logs/cron.log
It doesn't make sense to run the bootstrap in the same directory or in cron job folder. I've created a better and easy way to implement the cron job work. Please follow the below things to make your work easy and smart:
Create a cron job folder such as "cron" or "crobjob" etc. whatever you want.
Sometimes we need the cron job to run on a server with different interval like for 1 hr interval or 1-day interval that we can setup on the server.
Create a file in cron job folder like I created an "init.php", Now let's say you want to send a newsletter to users in once per day. You don't need to do the zend code in init.php.
So just set up the curl function in init.php and add the URL of your controller action in that curl function. Because our main purpose is that an action should be called on every day. for example, the URL should be like this:
https://www.example.com/cron/newsletters
So set up this URL in curl function and call this function in init.php in the same file.
In the above link, you can see "cron" is the controller and newsletters is the action where you can do your work, in the same way, don't need to run the bootstrap file etc.

Categories