Posted under Knowledge Base & PHP
Permalink
Tags Gotcha, Yoti
I was in the process of upgrading all aspects of the Microapps functionality to the latest versions, and in particular, was upgrading the Yoti SDK versions used as part of the Age Verification Microapp Identity API. I’ve already posted about the Java/Spring Boot issues I hit when upgrading the Java/Spring Boot Identity API. I also hit a couple of issues when upgrading the PHP version of the Identity API, which are detailed here as follows.
1/ To manage the PHP versions of the Yoti SDK, I was using PHP composer as detailed here. Rather than complicate matters for such a simple demo API, as per the linked post, I elected to use a simple PHP project which was not integrated to Composer within PHP. Composer functions such as install or upate were performed separately on the command line.
When doing this upgrade, I was using a new PC and so had to check out the code from scratch from Bitbucket. As a policy I do not check in IDE related files (in this case, the PHP version of eclipse), as I wish to keep checked in source IDE agnostic. I therefore cloned the repository on the command line, in a folder under the eclipse workspace, and then tried to create this as an eclipse project from existing files. Whenever I attempted this initially, I got the error ‘Cannot create project content in workspace’. After investigation I found this stack overflow post here on the subject, which says in the comments that this is in fact a long standing eclipse issue. I was able to create a project from existing files in a folder outside the workspace, but eclipse refused to do this inside the workspace, which is strange. It was possible to create the project outside the workspace, then copy the folder into the workspace, and then import it as an existing project, i.e. with all the eclipse project files already present. This all seemed unnecessarily hard though and certainly appeared to be a bug as per the post.
2/ When creating/importing the new project into eclipse, on several occasions I hit an issue where the resulting code had compilation errors in eclipse relating to the composer include files. After investigating, it appeared that due to the way I was importing/creating, eclipse was trying to interpret the type of project (possibly as a composer one) and set some complex invalid entries for the build path and include path which tripped everything up. In the end, I noted that importing just as a simple PHP project was fine and all the errors disappeared. Whilst this may not integrate eclipse fully with the underlying Composer structure, as before, I was not interested in doing this. The project was just a simple interface calling Yoti’s php api, with no other composer dependencies of mine. I therefore stuck with a simple project import and ensured that, however I went about the import/create, I told eclipse effectively ‘stop trying to be clever, just treat it all as a simple php project’. This worked fine.
I did note that unlike intellij (and indeed eclipse for java), control/clicking on a method did not appear to go to the method, or offer the choice of visiting either the declaration or the implementation. After checking online, this appears to be the norm – I could not see any posts indicating that ctrl/click or some variant of this would work in this way. There were however keyboard shortcuts to do this kind of thing, but I did not investigate further.
3/ In the end, my solution to both these issues was to use the import menu in eclipse and import directly from bitbucket into eclipse, creating a new project in the process. The double advantage of this was that the integration with the remote bitbucket was immediate as a result of the import, and creating the project in the workspace during the import did not give the error above under 1/.
To do this, I used the clone URI that bitbucket provided for cloning, but without the git command prefix. Whilst the initial import form has a ‘local directory’ next to the remote git uri field, this was not the target local folder – it would try to do a local import instead from this folder, and suppress the git uri. I therefore left this folder blank and proceeded with the next button. A subsequent screen had a local folder location field for where to place the imported/cloned project, and when placing this under the workspace, crucially, eclipse did not complain, and everything proceeded fine. An important point during this process was that I took great pains to ensure that any fields relating to the type of import were set to basic/simple eclipse project only, i.e. I told eclipse not to try to second guess the project type, and risk getting the errors I received above in 2/ again.
After doing this, the project looked fine in eclipse, with no compilation errors. I then updated the composer.json file as required, and manually ran ‘composer update –no-dev’ to update the vendor files, then did a refresh/revalidate in eclipse. This all worked fine.
4/ Another issue I hit was when accidentally missing out the pem file when deploying under zen hosting with the new version. When this happened, Yoti correctly returned an exception re the missing pem file, but the error code was set to 0, rather than to a specific http status as is done for the success case which gives a code of 200. Unfortunately, whilst this code of 0 was returned in the response body, the actual http status was set to 200 ok, as for success. This resulted in the age verification application assuming a successfully returned age of -1. In the java/Spring Boot version of the same api, I had elected to return all error conditions as a 404 for simplicity. This would be sensible i.e. if a broken or invalid token was sent to Yoti – Yoti would return an error stating that it could not decrypt the token, which should map to a 404. I did not want to get into mapping individual statuses to http responses as the mapping would not be easy/good anyway, and it did not feel right to map all errors to a 500 say, as in many typical cases this would not be appropriate, as in the incorrect or duplicate token usage as above.
I therefore did exactly the same for the PHP version as for the java one, for consistency. All 200 error codes were sent as an http response of 200 as expected, but anything else in the code field, which would not be a success, was sent as a 404. This solved the problem and all worked fine.
Comments Off on Issues when upgrading Yoti PHP Identity API to use v3 of the Yoti PHP api