Forem: Robert Radošić

Setting up Jetbrains' Remote Development For WSL

Robert Radošić — Mon, 03 Jan 2022 19:34:40 +0000

Intro

JetBrains family of IDEs recently got an update that introduced remote development features to almost all of their editors, albeit in a beta state. As claimed by JetBrains , remote development allows you, among other things, to:

Connect to remote environments from anywhere in seconds
Secure sensitive code on a remote server
Introduce your team to cloud dev environments
Streamline onboarding and tech interviews

But, what this finally enables is frictionless development with WSL on Windows machines. Anyone that has used Jetbrains' IDEs with WSL knows about indexing problems, git issues etc. With remote development all of these go away since all that is done on the actual WSL system and presented to you on the Windows side with the new JetBrains Client.

Setting up remote development is easy and I'm gonna show you how...

Requirements

Windows Pro or greater
WSL distro with SSH server enabled
A JetBrains IDE version 2021.3 or greater (PHPStorm in this case)

Setting up

As I said previously, if you have all of the requirements satisfied setting up the project is really easy.
When you open up your editor you're going to be presented with a project selection screen as usual but with a new remote development option

So, select this new option and let's continue. You are going to be asked your SSH username and server address. The address is "localhost" in case of WSL and the username is the one you chose during installation.
After that it's time to select your IDE, select whichever one you're using and select the folder of your project.

Note: If you're having problems with IDE backend installation you can use "other options" and upload the installer file manually.

When everything is finished the JetBrains Client will launch and you are ready to start developing.

Things to look out for

As this feature is still in beta some issues are to be expected. For example the IDE backend installation will fail in some cases but there is a manual workaround. Also, database tools have some weird issues, as well as the occasional UI glitch. Other than that, once it's out of beta it's definitely going to be the tool of choice when working with remote machines.

Integrating with the Erste Banking API

Robert Radošić — Mon, 26 Jul 2021 13:40:49 +0000

Intro

As a part of a larger project, we had to integrate with the Erste PSD2 API. Although it's mostly your standard OAuth flow, there are a few "gotchas" along the way. This post will guide you to getting authenticated and pulling transactions.

Developer Portal

Before you can start writing any code, you will need an Erste developer account. You can open one on the Erste developers portal where you will be able to choose the branch of the bank you will be integrating with and which of the APIs you will be using. Take note that the only API you can use without certification is the Corporate API. Luckily this was exactly the one we needed and didn't have to go through the certification process.

Among many options that are available on the portal dashboard, the only three that you are going to need to get started are OAuth settings, credentials, and the certificates section.

In the OAuth settings, you are going to set the callback URI, this is the URI to which the authorization code is going to be sent. If you don't have a local server that can accept HTTP requests, you can use something like RequestBin to output the request and get the authorization code.

In the certificates section, you will find the public and private keys which you can download and install to your devices' CA store.

Calling API endpoints

So, once we have the certificates installed and the callback URI setup, we can start calling the Erste API.

Consent ID

The first endpoint that we are going to call is the /consents API which is going to return our consent ID:

curl -X POST \
 https://webapi.developers.erstegroup.com/api/ebc/sandbox/v1/netapi/consents \
  -H 'Content-Type: application/json' \
  -H 'X-Request-ID: 4774477a-0508-4293-be86-6fca6f67adda' \
  -H 'psu-ip-address: 127.0.0.1' \
  -H 'web-api-key: WEB_API_KEY' \
  -d '{
  "access": {
    "accounts": [],
    "balances": [],
    "transactions": []
  },
  "recurringIndicator": false,
  "validUntil": "2019-06-30",
  "frequencyPerDay": 4,
  "combinedServiceIndicator": false
}'

Where the WEB_API_KEY is the API key in your developer dashboard.
The response will return the consent ID, save it somewhere as it's going to be needed in other requests.

OAuth URL

After we have obtained the consent token, we have to visit the URL with the following structure:

https://webapi.developers.erstegroup.com/api/ebc/sandbox/v1netapi/auth
    ?redirect_uri=REDIRECT_URI
    &client_id=CLIENT_ID
    &response_type=code
    &access_type=offline
    &state=loremipsum
    &code_challenge=loremipsum
    &code_challenge_method=S256
    &scope=AIS:CONSENT_ID%20openid%20offline_access

Where the variables are following:

REDIRECT_URI - the URI you put as the callback in the OAuth setting
CLIENT_ID - client ID from your dashboard
CONSENT_ID - consent ID from the previous request If you put the right details in the URL you will be greeted with an OAuth mocking tool where you can choose what type of user you want to mock, and what access you are going to give for their accounts.

Authorization code

Once you select all the options in the OAuth mocking tool you will be redirected to the URI you put in the OAuth setting. If you are using RequestBin you can now go through the request and get the authorization code from the request.

Bearer token

At this point, once we have obtained the authorization code and the consent token, we can finally call the /token endpoint and receive the Bearer token which will be used to get transactions, accounts, etc.

curl -X POST \
  https://webapi.developers.erstegroup.com/api/ebc/sandbox/v1/netapi/token \
  -H 'Content-Type: application/x-www-form-urlencoded'
  -d 'redirect_uri=REDIRECT_URI&client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=authorization_code&code_verifier=loremipsum&code=AUTHORIZATION_CODE'

Where the variables are following:

REDIRECT_URI - the URI you put as the callback in the OAuth setting
CLIENT_ID - client ID from your dashboard
CLIENT_SECRET - client secret from your dashboard
AUTHORIZATION_CODE - authorization code from the previous request

Calling other endpoints

Once you have the Bearer token you can use standard Bearer auth in the header of your requests. With this token, you can pull transactions and accounts from the sandbox. To go to production, the requirements will vary from country to country. The most common procedure will involve giving your VAT number and the SSL cert for the domain your app will be using.

If you are going to be integrating with the Croatian branch of the Erste bank using PHP take a look at our in-house library to help you get started.

Refactoring type annotations to PHP 7.4 type declarations with Rector

Robert Radošić — Mon, 08 Mar 2021 14:11:35 +0000

The problem

So, you have an older PHP project that uses type hinting via annotations and you would like to move away from those ugly annotations to nice inline type declarations.

From this:

<?php

declare(strict_types=1);

class SomeClass 
{
    /**
    * @var string
    */
    private $someProperty;
}

To this:

<?php

declare(strict_types=1);

class SomeClass 
{
    private string $someProperty;
}

Sure, you could do it manually but depending on the size of the project this could take anywhere from a day to a couple of weeks.

The solution

Well, worry not, this is where Rector comes in. Rector is a "tool for automated refactoring" that will make changes in your code based on pre-defined rules. One of those many rules will help us to automatically move type declarations from annotations to inline declarations and that rule is called TypedPropertyRector. So now that we know what Rector is and what rule to use, how do we use it?

First of all install Rector using composer
composer require rector/rector --dev
Next, use the init command to create the rector.php config file
vendor/bin/rector init

Now it's time to modify the config file to suit our use case

<?php
//rector.php

declare(strict_types=1);

use Rector\Php74\Rector\Property\TypedPropertyRector;
use Symfony\Component\DependencyInjection\Loader\Configurator\ContainerConfigurator;

return static function (ContainerConfigurator $containerConfigurator): void {
    $services = $containerConfigurator->services();
    $services->set(TypedPropertyRector::class);
};

Finally, you can either run Rector to process your files in the src directory
vendor/bin/rector process src or do a dry run to catch any errors that might pop up beforehand vendor/bin/rector process src --dry-run

Conclusion

Rector is an amazing tool that will let you do all sorts of improvements on your code and automate a lot of work when migrating to other PHP versions. It's also not a bad idea to consider using it as a part of your CI pipeline for automated code refactoring or even automated code review.