profile
viewpoint

SunMar/Behat-Laravel-Extension 0

Laravel extension for Behat functional testing.

SunMar/edifact 0

Tools to process EDI messages in UN/EDIFACT format

SunMar/edifact-mapping 0

Provides xml descriptions of EDIFACT Messages

SunMar/ignition 0

A beautiful error page for Laravel apps

SunMar/mail-mime-parser 0

An email parser written in PHP

SunMar/Mailu 0

Insular email distribution - mail server as Docker images

SunMar/php-iban 0

Generate, parse, validate, error-correct and present IBAN (and IIBAN) bank account information in PHP.

SunMar/PHP-on-Couch 0

Data Access Library to access a CouchDB server with PHP.

SunMar/PhpMetrics 0

Static analysis tool for PHP

issue openedpuppeteer/puppeteer

Last page display slash ('/') in the footer when footer is an empty string

Not sure if this is an issue with puppeteer or Chromium, but I'm not sure how to reproduce using only Chromium. If anybody has pointers on how I can try to reproduce using only Chromium that would be appreciated too, so I can verify if this is an issue in puppeteer or in Chromium.

The issue is that when printing to PDF and you enable displayHeaderFooter, but don't leave enough room for the footer (because for example you only want to use a header), a / is displayed in the bottom right corner of the last page of the PDF.

To reproduce install puppeteer and lorem-ipsum and run the following code:

const puppeteer = require('puppeteer');
const LoremIpsum = require("lorem-ipsum").LoremIpsum;

(async () => {
  const lorem = new LoremIpsum();
  const browser = await puppeteer.launch();
  const page = await browser.newPage();

  const html = '<html><body>' + lorem.generateParagraphs(50) + '</body></html>';

  await page.setContent(html);
  await page.pdf({
    path: 'slash.pdf',
    format: 'A4',
    displayHeaderFooter: true,
    headerTemplate: '<div style="font-size: 16pt; font-weight: bold;">foobar</div>',
    margin: {
      top: 75,
      bottom: 0,
    }
  });

  await browser.close();
})();

Now open the generated slash.pdf and you see at the bottom of the last page there is a / appearing out of nowhere. If you play with the margins and increase the bottom margin to 34 or above, you get the default about:blank 3/3 footer. But if the bottom margin is 33 or lower, the footer doesn't fit and the / appears, but only on the last page.

Setting the footer template to an empty string ('') doesn't work because that will cause the footer template to still default to Chromium's standard about:blank footer, which will cause the / to show. But if you set it to anything, even just a single space (footerTemplate: ' '), the / disappears.

created time in 4 days

issue commentfacade/ignition

QueueServiceProvider optional

Sure, created #287 :).

SunMar

comment created time in 25 days

PR opened facade/ignition

IgnitionServiceProvider only setup queues when queue is available

Only setup the queues if we actually have queues available :) (see #272).

+5 -2

0 comment

1 changed file

pr created time in 25 days

create barnchSunMar/ignition

branch : feature/only-bind-queue-if-available

created branch time in 25 days

issue openedglobalcitizen/php-iban

IBAN secret or not

Hi @globalcitizen,

Thank you for the great library! It really helps to be able to do IBAN validation when dealing with bank accounts.

When going through the commits of the most recents releases I came across the falsehood you added that IBANs are not secrets (https://github.com/globalcitizen/php-iban/commit/d568c5462eda0a47f8a929d82a8d67be8cd0ba8c).

Even though it's harder nowadays to abuse an IBAN solely by knowing the number, when it is the IBAN of an actual person (rather than a company) it is considered what's called Personal Identifiable Information (PII). That makes it sensitive information that should be protected and I wouldn't want to call it a "public identifier", as it is not public. That is private information. In the EU, storing and using PII (including IBANs of natural people) is strictly regulated under the privacy regulations set forth in the GDPR. It is also not public since there is no website where you can just type in the name of a person and get their bank account, and you also can't call a bank and ask what someone's IBAN is, they won't provide it.

My suggestion would be to remove this falsehood again. Whether or not IBANs should be secret really depends on the context. What is the use case of the IBAN? What type of application are we dealing with? Is it an IBAN of a company or a natural person? What are the local laws and regulations? I don't think there is a single yes or no answer on whether IBANs should be kept secret or not.

created time in a month

push eventSunMar/Behat-Laravel-Extension

SunMar

commit sha d4677d2bb4e1d6bf8165d49817ffaf463e0e3e60

Reboot Kernel before scenario instead of after Rebooting the kernel after a scenario instead of before makes running tests inconsistent. This is because anything that is done during suite setup (`@BeforeSuite`) can taint the kernel and carry over into the first scenario, but won't be present for the second scenario and onwards because those will have had their kernels rebooted. To make sure that `@BeforeSuite` also uses a clean kernel and is not tainted by the last scenario if you are running multiple suites, the kernel should also be rebooted after every suite. Take for example singletons. Let's say in our service provider we have the following: ``` $this->app->bind(MyInterface::class, MyConcrete::class); $this->app->singleton(MyService::class, function() { return new MyService($this->app->make(MyInterface::class)); }); // the anonymous function here is redundant of course, it's just to show that we need a MyInterface when creating a MyService ``` Now in an `@BeforeSuite` we do: ``` App::make(MyService::class)->bootstrap(); ``` This will create a `MyService` with a `MyConcrete`. An in an `@BeforeScenario` we do: ``` $this->app->bind(MyInterface::class, MyConcreteTest::class); ``` Now when we run the test, and at some point it runs into a `$this->app->make(MyService::class)` it is supposed to create a `MyService` with a `MyConcreteTest`. But if it is the first test in the suite, we get returned the `MyService` with the `MyConcrete` because it's a singleton and rebinding `MyInterface` will not recreate `MyService`. So if the scenario is run as the first test in the suite we get a `MyService` with a `MyConcrete`, but if it's run as the second or later test we get a `MyService` with a `MyConcreteTest`. Now if we only subscribe to `ScenarioTested::BEFORE` we solve this problem, but we also create a problem if you're running more than one suite. Then suddenly the `@BeforeSuite` will get a `MyService` with a `MyConcreteTest` if that scenario was the last in the previous suite to run, so we want to make sure we also reboot the kernel after a suite so we can start with a clean kernel in our next suite as well.

view details

push time in a month

PR opened laracasts/Behat-Laravel-Extension

Reboot Kernel before scenario instead of after

Rebooting the kernel after a scenario instead of before makes running tests inconsistent. This is because anything that is done during suite setup (@BeforeSuite) can taint the kernel and carry over into the first scenario, but won't be present for the second scenario and onwards because those will have had their kernels rebooted. To make sure that @BeforeSuite also uses a clean kernel and is not tainted by the last scenario if you are running multiple suites, the kernel should also be rebooted after every suite.

Take for example singletons. Let's say in our service provider we have the following:

$this->app->bind(MyInterface::class, MyConcrete::class);
$this->app->singleton(MyService::class, function() { return new MyService($this->app->make(MyInterface::class)); }); // the anonymous function here is redundant of course, it's just to show that we need a MyInterface when creating a MyService

Now in an @BeforeSuite we do:

App::make(MyService::class)->bootstrap();

This will create a MyService with a MyConcrete.

An in an @BeforeScenario we do:

$this->app->bind(MyInterface::class, MyConcreteTest::class);

Now when we run the test, and at some point it runs into a $this->app->make(MyService::class) it is supposed to create a MyService with a MyConcreteTest. But if it is the first test in the suite, we get returned the MyService with the MyConcrete because it's a singleton and rebinding MyInterface will not recreate MyService. So if the scenario is run as the first test in the suite we get a MyService with a MyConcrete, but if it's run as the second or later test we get a MyService with a MyConcreteTest.

Now if we only subscribe to ScenarioTested::BEFORE we solve this problem, but we also create a problem if you're running more than one suite. Then suddenly the @BeforeSuite will get a MyService with a MyConcreteTest if that scenario was the last in the previous suite to run, so we want to make sure we also reboot the kernel after a suite so we can start with a clean kernel in our next suite as well.

+4 -2

0 comment

1 changed file

pr created time in a month

push eventSunMar/Behat-Laravel-Extension

SunMar

commit sha 861cd267a04f37042d115480bfe92c59cf28b82f

Reboot Kernel before scenario instead of after Rebooting the kernel after a scenario instead of before makes running tests inconsistent. This is because anything that is done during suite setup (`@BeforeSuite`) can taint the kernel and carry over into the first scenario, but won't be present for the second scenario and onwards because those will have had their kernels rebooted. To make sure that `@BeforeSuite` also uses a clean kernel and is not tainted by the last scenario if you are running multiple suites, the kernel should also be rebooted after every suite. Take for example singletons. Let's say in our service provider we have the following: ``` $this->app->bind(MyInterface::class, MyConcrete::class); $this->app->singleton(MyService::class, function() { return new MyService($this->app->make(MyInterface::class)); }); // the anonymous function here is redundant of course, it's just to show that we need a MyInterface when creating a MyService ``` Now in an `@BeforeSuite` we do: ``` App::make(MyService::class)->bootstrap(); ``` This will create a `MyService` with a `MyConcrete`. An in an `@BeforeScenario` we do: ``` $this->app->bind(MyInterface::class, MyConcreteTest::class); ``` Now when we run the test, and at some point it runs into a `$this->app->make(MyService::class)` it is supposed to create a `MyService` with a `MyConcreteTest`. But if it is the first test in the suite, we get returned the `MyService` with the `MyConcrete` because it's a singleton and rebinding `MyInterface` will not recreate `MyService`. So if the scenario is run as the first test in the suite we get a `MyService` with a `MyConcrete`, but if it's run as the second or later test we get a `MyService` with a `MyConcreteTest`. Now if we only subscribe to `ScenarioTested::BEFORE` we solve this problem, but we also create a problem if you're running more than one suite. Then suddenly the `@BeforeSuite` will get a `MyService` with a `MyConcreteTest` if that scenario was the last in the previous suite to run, so we want to make sure we also reboot the kernel after a suite so we can start with a clean kernel in our next suite as well.

view details

push time in a month

fork SunMar/Behat-Laravel-Extension

Laravel extension for Behat functional testing.

fork in a month

more