Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
The recommended Github work flow here is for developers to submit code and documentation contributions to MOSIP open source repositories.
Fork MOSIP repository of interest from https://github.com/mosip/
Clone the fork to your local machine. Eg:
Set upstream project as the original from where you forked. Eg:
Make sure you never directly push to upstream.
Confirm the origin and upstream.
Create a new issue in MOSIP Jira.
You may work on master
, switch to a branch (like Release branch) or create a new branch.
Make sure you are up-to-date with upstream repo.
Once you are done with the work, commit your changes referring to Jira number in the commit message. Eg:
Once again ensure that you are up-to-date with upstream repo as it may have moved forward.
Build and test your code. Make sure it follows the coding guidelines.
Push to your forked repo (origin).
Create a pull-request on your forked repo. Direct the pull-request to master
or any specific branch on upstream (like a Release branch).
Make sure the automatic tests on Github for your pull-request pass.
The pull-request shall be reviewed by reviewers.
MOSIP is developed as an open source framework project. The code developed complies with the Java standards and best practices.
This document gives various RESTful webservice standards which have to be followed during the MOSIP development.
This document covers the coding standards, which are followed by the RESTful webservice developers.
The syntax of the URL of the RESTful webservice should be as follows for all the modules except Kernel,
https://<IP_ADDRESS>:<PORT>/<MODULE_NAME>/<VERSION>/<RESOURCE_NAME>/<PARAMETERS_AND_VALUES_IF_ANY>
For example,
https://mosip.io/pre-registration/v1/document
Only in case of Kernel modules, the <MODULE_NAME> is not included. The format is as follows,
https://<IP_ADDRESS>:<PORT>/<VERSION>/<RESOURCE_NAME>/<PARAMETERS_AND_VALUES_IF_ANY>
Following URL is an example for Kernel,
https://mosip.io/v1/emailnotifier
The convention is, before <RESOURCE_NAME>, we should have the version number.
The URL is the sentence, the resources are nouns and the HTTP methods are verbs. The URL, before the parameters, should contain only spinal case ( - ). The URL, before the parameters, should not contain snake case ( _ ) or camel case. NOTE: The parameters can contain snake case or camel case.
Use nouns for CRUD operations. Resource GET read POST create PUT update DELETE delete /preenrolments Returns list of pre enrolments Creates a new pre enrolment Bulk updates Delete all preenrolments /preenrolments/123 Returns a particular pre enrolment Updates a specific car Deletes a specific car
For operations, wherever applicable the operations can be added as part of the URL itself. For example, /getAllPreenrolments /createNewEnrolment /deleteAllPreenrolments
Use the plural nouns in the resource names if there is CRUD operations. For example,
https://mosip.io/pre-registration/v1/individuals
Prefer
https://mosip.io/pre-registration/v1/individual
Avoid
In other cases, use singulars in the nouns. For example,
https://mosip.io/pre-registration/v1/OTP
The actions are added in the URL, wherever applicable. For example,
https://mosip.io/pre-registration/v1/OTP/generator
https://mosip.io/pre-registration/v1/OTP/validator
Use only the intended purpose of the HTTP methods. For example, do not use POST to update a resource or PUT to create a resource.
In all the success cases and failure cases, 200 HTTP Status code is returned. Based on the "errors" JSON element in the response, the caller can decide whether the call is success or failure.
When the caller want to identify the resource, the path param is used. For example,
https://mosip.io/pre-registration/v1/individuals/id1234
The filter has to be applied via the URL parameters. For example,
https://mosip.io/pre-registration/v1/individuals/id1234?city=someCityName&pincode=473822
In case if the results have to be sorted, it can be mentioned in the URL parameter named sort. For example,
https://mosip.io/pre-registration/v1/individuals/1234?sort=firstName
In case of pagination, the page number can be mentioned in the parameter by the name “page”. For example,
https://mosip.io/pre-registration/v1/individuals/1234?page=15
Always use SSL for the services. No services should be exposed without SSL.
Always version the service. The version have to be mentioned in the URL of the service after the hostname (and port number, if any). For example,
https://mosip.io/pre-registration/v1/individuals/1234
--> Except Kernel module
https://mosip.io/v1/individuals/1234
--> Kernel module
Always go with the design first approach. First, define the Swagger specification and publish to the Swagger UI after getting it reviewed. The coding should be started after the design is completed and the specification is completed in Swagger.
There are 3 sections in the Request.
15.1. Request headers: This will contain 3 mandatory fields. They are "id", "version" and "requesttime". The "requesttime" have to be in UTC standard ISO8601 format
15.2. Request meta data: This is an optional field. If the service is expecting any metadata, they can be passed here.
15.3. Request payload: This is an optional field. The request payload goes here.
For example,
Request:
There are 4 sections in the Response.
16.1. Response headers: This will contain 3 mandatory fields. They are "id", "version" and "requesttime". The "requesttime" have to be in UTC standard ISO8601 format
16.2. Response meta data: This is an optional field. If the service is expecting any metadata, they can be passed here.
16.3. Response payload: The response payload goes here.
16.4. Errors: The Errors array goes here. Even, in case of single error, the error have to be in an array. This is an optional field. In case if the service doesn't contains error, this element will not be there in the response.
For example,
Response:
In case, there is no request payload or path params or URL params, only the version will be present in the URL.
Guidelines to implement Authorization and Authentication techniques in the Angular application are detailed in this document.
Before going in to the components let us discuss the following flows of Authorization and Authentication.
Initially a login request is made passing user credentials to a REST API as specified in the SPECS of that API.
In the response of a successful authentication you will receive user details and an auth_token as the value of the header "Authorization".
Now the received auth token has to be stored and re-used. For example let us use sessionStorage to store the auth_token under the key "TOKEN".
Now any kind of HTTP/HTTPS requests we make from the application has to be sent by adding a header "Authorization" and value of auth_token stored in sessionStorage with key by name "Token" for the purpose of authentication.
If the response comes back with a new token which might be because of previous token getting expired or refresh token mechanisms that happen in the backend, we need to replace the old token with the new one in the session storage.
After successful login the user details are sent to the client(Angular application/ Browser).
Now store the userDetails in the sessionStorage for example under the key "UserDetails".
Now we need to hide some pages/components/user action elements etc. based on the roles that the user possess.
To implement the Authentication and Authorization flows mentioned above, all we need to do is implement an Interceptor and a Directive which were mentioned above and detailed below.
Tasks to be implemented in a Client/UI Http interceptor are:
Append "Authorization" header to the request using the token value stored in the session storage.
Replace/Add the session storage token value with the one received in the response "Authorization" headers.
Below code implements the requirements mentioned above:
Role of the Roles directive is to fetch roles from UserDetails stored in the session storage and verify if the user has required roles to perform some action or read some details and restrict access accordingly.
Below code implements the requirements mentioned above:
Now inject the above interceptor and directive in the app.module.ts as follows
To activate/deactivate => show/hide element all we need to do is add the appRole attribute to the HTML element as shown below:
In the above sample, the add button will only be visible for users with DIVISION_ADMIN or SUPERVISOR role.
Note: Above mentioned code snippets are not the final implementations. Based on the API specs and a few other factors the method implementations might change a bit. However, the component structures remain the same.
This document lists out the instructions on how to use the in a Spring Boot application.
Step 1:
Step 2:
Step 3:
Add the Auth Adapter module to your project as a maven dependency
Add ComponentScan annotation as shown below to your project. This is to create auth adapter bean.
To restrict access to your endpoints, you need to add the @PreAuthorize annotation. Look at the below example for reference.
Note: Now we support only hasRole and hasAnyRole methods.
To make any kind of HTTP or HTTPS calls to a mosip's micro service that also injected the Auth Adapter, use the standard RestTemplate capabilities as shown below.
Intially autowire the RestTemplate in the class where you are going to make an API call.
Now make the call using the autowired restTemplate as shown in the sample below:
Note: Do not create a new instance of the RestTemplate instead use the autowired one.
There are few more methods available apart from hasAnyRole like hasRole. Look in to the documentation for more details.
In MOSIP, the source code modules are categorized under different repositories:
Commons - This contains common reusable library modules and service modules
Kernel - The collection of common reusable library modules and services
ID-Repo - The ID Repository services used by many of the MOSIP modules
Feature Specific Modules (for example)
registration
registration-processor
pre-registration
id-authentication
If a new source code module is planned to be added, and if it is a reusable library / service on which other modules will be depending on, then it should be added under Commons, otherwise, it can be created as a separate repository.
Source code of any feature in MOSIP will be organized as below:
feature-parent
feature-core - jar
feature-common - jar
feature-service-1 - SpringBoot service
feature-service-2 - SpringBoot service
This should be a POM module that aggregates all the sub-modules. This should contain,
List of all sub-modules
Common properties such as versions used by all sub-modules
Common dependencies used by all of the sub-modules
Common maven-plugins used by all sub modules
There should be a JAR module that defines core source code files such as,
APIs (Application Programming Interfaces)
SPIs (Service Provider Interfaces)
Common Utility classes
Helper classes
DTO classes
Custom Exception classes
There can be a JAR module that provides abstract base implementations or common implementations of the APIs and SPIs. Other modules such as service module will be depending on this module using the API/SPI implementations or extending their base implementations.
Any Service implementation class should have 'Impl' suffix.
A feature can have one or more Spring Boot Service modules, each will have one or more related services.
Each Spring Boot Service Modules will be deployed as a separate deployment unit such as a docker container. So each will contain the separate Dockerfile
containing the docker build instructions for that module.
Each Spring Boot Service Modules should be configured with Swagger configuration (except specific cases where) for easy understanding of the feature, easy unit-testing and verification for the developers.
No Spring Boot Service module should be used as a dependency to any other module. Any such code dependency should be going inside the Common Implementation module.
In MOSIP following naming of Class/Interfaces their names should be of Camel cases, without any underscore.
They should have following suffixes in their names and they should be under appropriate package name based on their category,
XyzService - For a Service interface. A service class should not be annotated with @Service
. This will be in the core-module. This will be under *.spi.xyz.service
package.
XyzServiceImpl - For a Spring Service implementation class. This class should be annotated with @Service
. This should not be defined in a core-module. It will be defined in a common
or service
module. This will be under *.spi.xyz.service.impl
package.
XyzRequestDto - For a Request Data Transfer class in a Service. This will be in the core-module. This will be under *.xyz.dto
package.
XyzResponseDto - For a Response Data Transfer class in a Service. This will be in the core-module. This will be under *.xyz.dto
package.
XyzEntity or XyzDao- For an Entity/ Data Access class, which will use JPA annotations for the entity. This will be in the core-module. This will be under or *.xyz.entity
or *.xyz.dao
package.
XyzRepository - For a JPA Repository interface, which will be extending the base MOSIP Repository interface io.mosip.kernel.core.dataaccess.spi.repository.BaseRepository
. This will be annotated with @Repository annotation. This will be under *.xyz.repository
package.
XyzController - For a Spring Controller class, which will be annotated with @Controller annotation. This will be under *.xyz.controller
package.
XyzConfiguration - For a Spring configuration, which will be annotated with @Configuration. This will be under *.xyz.config
package.
XyzUtil or XyzUtils - For a utility class. This will expose public static utility methods. This will be under *.xyz.util
package.
XyzHelper - For a helper class. This will be a Spring Component class annotated with @Component. This will expose public instance helper methods. This will be under *.xyz.helper
package.
XyzManager - For any management class. Also for any class that will connect external module using REST service calls. This will be a Spring Component class annotated with @Component.
XyzConstants - For file storing constants. Please prefer to have a Constants file to define common and related constants used across the classes in a feature. This can be inside the core-module or common-module. This will be under *.xyz.constant
package.
XyzException - For a custom exception, which will be extending io.mosip.kernel.core.exception.BaseCheckedException
and io.mosip.kernel.core.exception.BaseUncheckedException
. This will be defined in a core-module. This will be under *.xyz.exception
package.
XyzExceptionHandler - For the centralized exception handler class in a service-module, annotated with @ControllerAdvice
or @RestControllerAdvice
annotation. This will be under *.xyz.exception
package.
XyzFactory - For any class/interface defining Factory design pattern. This will be under *.xyz.factory
package.
Xyzbuilder - For any class/interface defining Builder design pattern. This will be under *.xyz.builder
package.
XyzFacade - For any class/interface defining Facade design pattern.
XyzImpl - For any implementation class that extends an API/SPI interface.
A service implementation should be always with a combination of Service Interface and its Spring Service Implementation Class. It should not be without a Service Interface defined in core-module.
Any Spring Component will be annotated with @Component
. A component may or may not be implementing an interface.
Any dependency injection of a Spring Service should only to be assigned to a variable of its Service Interface type but not to its Implementation class type.
For dependency injection of a Spring Component should be assigned to a variable its Interface type if any, otherwise to the class type.
All data classes such as DTOs, Entity classes use Lombok annotations to automatically create appropriate constructors, getters and setters.
Make sure to setup the IDE used for the development for using Lombok.
Any JPA repository created in MOSIP should be extending the base MOSIP Repository interface io.mosip.kernel.core.dataaccess.spi.repository.BaseRepository
.
Appropriate database configurations properties should be added to the app configuration file.
MOSIP has many common libraries and services implemented under Commons/Kernel repository.
Kernel-Core module contains may common utility classes such as Loggers, DateUtils, StringUtils and Crypto-Core etc… Also many utility services such as Kernel-KeyManager, Kernel-CryptoService, Kernel-Audit-Service, Kernel-Auth-Service, etc... .
If any common utility needs to be implemented, first check Commons/Kernel if such utility is already present and make sure it is not already implemented in Commons/Kernel. It is always welcomed to contribute any new features/ bug fixes for the existing utilities, instead of creating a new utility.
Any request and response content in a service in MOSIP should be of application/json content type.
Any byte arrays to be returned in response should be Base-64-URL encoded within the response.
If any sensitive information is getting transferred in the request/response, the request/response block should be encrypted using the MOSIP public key
.
Any service in MOSIP should never return error code other than 200. One or more errors to be reported in the response be returned as an array as part of "errors"
attribute.
Each of the "error"
attribute should under "errors"
should have "errorCode"
, "errorMessage
" and an optional "actionMessage"
. * For any service, possible "errorCode"
, "errorMessage"
and the optional "actionMessage"
should be properly listed documented in its API specification.
Any request/response body should have proper meta-data such as "id
, "version"
and "requestTime"
/"responseTime"
, etc... .
For example:
The number of lines in the Java files is restricted to 2000 lines. Beyond 2000 lines, the java file is refactored into multiple files.
Each java file contains one public class or interface.
When some private classes and interfaces are associated, this can be in the same file.
Declare the public class and interface as the first declaration in the file.
When a java file is written, the following order is maintained,
The beginning comment should be in a C-style comment. Following is the format of the comment.
The first non-comment line is the package statement.
After a line-break below the package statement, import statements are placed. The import statements are grouped and segregated by a line-break. For example,
Do not use asterisk symbol while importing packages.
This comment will be going in to the Javadocs
Then the public class or interface is defined.
Then other private class or interface are followed.
Following is the order of elements inside the class declaration
Constant fields (static and final fields) should be on the top inside a Class
Then any non-final static fields are followed
The public class variables are followed by the protected and the private variables. These can be final or non-final fields.
Initializing Fields in a class
Do not initialize non-primitive fields with null in a Class;
Always initialize non-static fields from constructors in a Class.
Avoid using static non-final fields in a class. If it required for any specific reason, avoid initializing it in a constructor or a post-construct method.
Avoid using static initializers to initialize static final/non-final fields, instead create private static methods and call it for initializing static fields.
The constructor declarations ordered by the number of parameters.
The methods are ordered by the functionality. The methods need not to be in the order of scope or accessibility.
The indentation unit it TAB.
The number of characters in a line should not exceed 80 characters
When the number of characters exceed the limit, the line should be broken into multiple lines. The following standard is used during the line breaks,
Break the line after the comma
Break before the operator
From higher-level breaks go to the lower-level breaks.
Align the new line with the beginning of the expression at the same level on the previous line.
There are two types of comments in Java.
Implementation comments
Documentation comments
Both the comment types are used in the source code of MOSIP.
This is the comment type used for better understanding of the code. Most of the times, the source code will be maintained by different people. The programmer writes these comments so that the other programmers will come to know the functionality of the code in plain English language. Following lines are used.
Java source code can have their implementation comments in various parts of code blocks/lines with appropriate description about what the code block or line is doing.
Specifically the if-else if-else
conditions can have their descriptions about their various conditional expressions.
Any complex piece of code such as a regular expression / mathematical expression can be described with appropriate descriptions about it.
When the developer needs to explain in detail about some functionality, block comments are used. Block comments are used anywhere in the code. It can be for the class or interface declarations or it can be within the java methods also. Example of block comments:
Single line comments are used for short description. For example,
Trailing comments are given in the same line where the source code resides. For example,
The end-of-line comments are also used in the source file. For example,
Documentation comments are used to generate the javadoc files.
Every source code file in Java should have proper Java Documentation such as description, Author and Version.
All Classes, Interfaces, Methods, Fields should have appropriate clear description about each.
A method documentation should have description about all parameters, exceptions thrown and return value.
Documentation comments can be of two kinds:
Single line documentation comment: /** COMMENT */
Multi-line documentation comment:
Example:
One variable is declared per line.
Variables are declared at the beginning of the code block. For example,
No space between a method name and the parenthesis "(" starting its parameter list
Open brace "{" appears at the end of the same line as the declaration statement
Closing brace "}" starts a line by itself indented to match its corresponding opening statement,
Except when it is a null statement the "}" should appear immediately after the "{"
An empty line is there in between the method declarations.
A method should follow the "Single Responsibility" principle that will perform only one task. If it seems to do multiple sub-tasks, each sub-tasks should be created as a new method and then be invoked in that method.
If there is a logic even of a single line getting repeated in more than one place, it should be made as a separate method.
A method line count should not exceed 80 lines. If required break the blocks of code in the method to separate methods.
Methods are separated by a blank line.
Never re-assign a parameter value. This may lead to unpredictable bugs.
Don't use too many number of parameters. Keep the maximum number of method parameters to 5 for simplicity.
Prefer method parameter type to be more generic such as a Super Interface or Super Class. For example, List
instead of ArrayList
.
Never return null for an Array return type. Return an empty array of 0 like return new String[0]
.
Never return null for a Set/List/Map collection return types. Return corresponding empty values such as Collections.emptySet()
, Collections.emptyList()
or Collections.emptyMap()
;
Prefer method return type to be more generic such as a Super Interface or Super Class. For example, List
instead of ArrayList
.
Avoid having multiple return statements in a method. Prefer to provide a single point of exit to a method. For example:
Use Optional
return type to avoid null checking. When there is possible to return null
for a method, return Optional.empty()
.
Use OptionalInt
, OptionalLong
return types for a method when there is an unknown value of Integer/Long to be returned like -1
;
Each line should contain at most one statement. Example:
Compound statements are statements that contain lists of statements enclosed in braces
The enclosed statements should be indented one more level than the compound statement.
The opening brace should be at the end of the line that begins the compound statement; the closing brace should begin a line and be indented to the beginning of the compound statement.
Braces are used around all statements, even single statements, when they are part of a control structure, such as an if-else or for statement. This makes it easier to add statements without accidentally introducing bugs due to forgetting to add braces. For example:
A return statement with a value should not use parentheses unless they make the return value more obvious in some way. Example:
Refer to Method return statement for more information.
Always curly braces are used in the if-else statements. Even though there is a single statement below the if-else statement, curly braces is used. For example,
If there is a Boolean value to be returned in a method or assigned to a variable based on an if-else condition, the condition itself should be returned or assigned instead of true
or false
for the condition. For example,
Prefer "switch" statement when possible over having multiple “if-else if-else if-else” statements.
If any binary operator is used before "?" in the ternary operator, then parentheses is used.
Prefer if-else statement over conditional expressions if it gets complex with the condition or the statements.
Avoid using nested conditional expressions for better readability.
A switch statement should have the following form:
Every time a case falls through (doesn't include a break statement), add a comment where the break statement would normally be. This is shown in the preceding code example with the /* falls through */
comment.
Every switch statement should include a default
case. The break in the default case is redundant, but it prevents a fall-through error if later another case is added.
Only for the following situations 2 blank lines are used,
Between 2 different sections of the source file
If you have more than one class or interface, use 2 blank lines
Only for the following situations, 1 blank line is used,
Between method declarations.
Between the variable declarations and the method code.
Before the block comment or line comment.
To provide a better readability in between logical blocks, an empty line are used, wherever applicable.
Under the following circumstances, blank space are used,
When a keyword followed by parenthesis, a blank space should be given after the keyword. For example,
In the argument list, the parameters are given a space after comma.
All the package name in MOSIP application starts with io.mosip. Refer to Classes/Interfaces in MOSIP section for various kinds or classes and the package names under which they should be kept.
The names given to classes are always nouns and in camel case. Refer to Classes/Interfaces in MOSIP section for various kinds or classes and their names.
The names given to interface is always noun and in camel case. Refer to Classes/Interfaces in MOSIP section for various kinds or interfaces and their names.
The method names are always verbs and in camel case. For example
The variable names are short and meaningful. Any new observer can understand the meaning of the variable. No single letter variable names are used. Camel case is used when declaring variables.
The constants are given the name in capital letters. The words in the names are separated by underscore.
String literals should not be used in the code directly. Declare them as constant in the class.
Magic Numbers should not be used in code, they should be declared as constants.
Create XyzConstants class to group related and reused constants within a module/feature.
The instance variables should not be made public unless you have a specific reason.
Provide the most restrictive access to the fields, methods and Inner Classes such as private
, default or protected
. Avoid giving public
access to them unless it is really required. Avoid using public non-final fields in a Class.
Always use the class name to call the static method. For example,
Numerical values should not be used in the code directly. Declare them and use it in the code. For example,
Avoid multiple assignments in the same line. For example,
Prefer primitive type variables over boxed types wherever possible. For example, prefer int
, boolean
and long
over their Boxed counterparts such as Integer
, Boolean
and Long
.
Prefer variable type to be more generic such as a Super Interface or Super Class. For example, List
instead of ArrayList
.
Use Optional
return type in a method to avoid null checking. When there is possible to return null
for a method, return Optional.empty()
.
Use OptionalInt
or OptionalLong
return type in a method when there is an unknown value of Integer/Long to be returned like -1
;
Avoid getting value from Optional
using Optional.get()
without checking for Optional.isPresent()
condition, otherwise use Optional.orElse()
.
Use primitive optional classes such as OptionalInt
or OptionalLong
over Optional<Integer>
or Optional<Long>
.
Prefer Method Reference over a Lambda Expression
Keep Lambda Expressions Short and Self-explanatory so that it is easy to understand. . Provide clear understandable name to the parameters in Lambda Expressions.
Always use parameter type inference. For example,
Do not use the parenthesis for a single parameter lambda expression.
Use “Effectively Final” Variables in Lambda Expressions. It is not required to mark every target variable as final.
Avoid mutating Object Variables in Lambda Expression.
Avoid using the block lambdas wherever an expression lambda are used. For example:
Prefer Standard Functional Interfaces over creating a similar one unless it is really required. Use Standard Functional interfaces, which are gathered in the java.util.function
package, satisfy most developers' needs in providing target types for lambda expressions and method references.
On a new Functional Interface declaration always use @FunctionalInterface
annotation. This is not only for the documentation purpose but also to avoid accidentally breaking the Functional Interface behavior.
Instantiate Functional Interfaces with Lambda Expressions instead of creating anonymous inner class instances for that.
Whenever calling the functional interface, place them at last in the parameter list.
For example:
Prefer Streams over for loops. Streams are more readable and functional than the "for" loops, as they support operations such as map, flatMap, filter, reduce and collect.
Exception handling in the streams are carefully handled.
Avoid mutating objects within Collection.forEach()
or Stream.forEach()
, use Stream.collect()
instead. For example use Stream.collect(Collectors.toList())
instead of mutating a list for collecting elements to a list.
Use parallel streams where ever possible to boost performance, whenever it does not involve sort/order/limit intermediate operations.
MOSIP applications should never allow to exit abruptly because of a critical error. Even if there is a critical error there should be a graceful exit with proper information about the error.
Each feature should be defining their own Checked and Unchecked Exceptions by extending io.mosip.kernel.core.exception.BaseCheckedException
and io.mosip.kernel.core.exception.BaseUncheckedException
.
The Checked and Unchecked exceptions should be used appropriately as needed. Make sure which one to use when based on the exception handling requirement.
Throw specific exceptions in a method, rather than generic exceptions. For example,
The exceptions are documented clearly. For example,
Always prefer to use try-with-resource block when applicable like instantiating a Input or Output stream/reader or Connection, which are AutoCloseable.
The following example uses a try-with-resources statement to automatically close a java.sql.Statement
object:
A try-with-resources statement can have catch and finally blocks just like an ordinary try statement.
Always catch specific exceptions over a more generic exceptions like Exception/Throwable class. For example,
Never leave a catch block empty. Either handle the exception, or say proper reason for doing nothing in it.
Use multi-catch blocks wherever possible to club common handling of multiple exceptions.
Always log exceptions to file in a catch block for debugging purpose.
Error and Throwable are never caught in MOSIP.
Any service module should handle their exceptions in a common place such as a common Exception Handler which can be annotated with @ControllerAdvice
or @RestControllerAdvice
Any service in MOSIP should never return error code other than 200. One or more errors to be reported in the response be returned as an array as part of "errors"
attribute.
Logs are classified and logged accordingly. Following are the various log levels used in the MOSIP application.
TRACE
DEBUG
INFO
WARN
ERROR
The log levels are configured according to the environment such as Development, Testing, UAT or Production. For example, the log levels in production is from WARN. Whereas in Development and Testing environment, it is from TRACE.
MOSIP's log component from the core-kernel is used to log entries. The log module in the core-kernel is used to log all the log entries.
First create a logger utility class under the core module of the feature like below:
To log any information/error/debug in a class,
create a logger instance in that class as below: private static Logger mosipLogger = XYZLogger.getLogger(MyClass.class);
In appropriate places invoke the appropriate log method of mosipLogger such as error
, debug
or info
with appropriate parameters passed to it.
Every log entry contains the following format,
For example,
Never log any sensitive information such as user credentials, individual identity information to the log, mask the data if required before logging.
Care should be taken, not to log any sensitive information is logged. Modules leads to review the code to ensure that no sensitive information is logged.
Any service in MOSIP should invoke Kernel's AuditManager REST Service for audit logging of the status of the services such as
Success
Failure
Exception occurred - the error codes and error messages.
Define the appropriate Audit Modules and Audit Events for any feature and use pass them appropriately in the Audit Parameters while invoking the Audit REST service.
Make sure to invoke the Audit REST service Asynchronously to prevent any time lagging in response because of the Audit REST service call.
Apache Commons is used to handle the common utilities like StringUtil, FileUtil, Hashcode, toString, null check etc., are
In case if Apache Commons doesn't have the necessary utilities, the util project from mosip-core is used.
Following are the miscellaneous practices which are followed in MOSIP.
Parenthesis are used in the code liberally to improve the readability and for precedence clarity.
Never type cast a variable without doing instanceof
checking.
Avoid unnecessary type casting when the type of the value/expression is already assigned to a correct variable type/return type.
Avoid using Generic classes without Parameter types. For example:
Use diamond operator while constructing Generic objects. For example:
While chaining multiple method calls, keep one method call per line for better clarity and easy debugging of any issue (especially to get line number in exception stack trace where exactly is the error/exception occurs). For example:
Special comments are used to give a hint for further development. Following are the special comments used in the MOSIP project,
TODO
FIXME
NOTE
OPTIMIZE
It should be made sure to track the above comments, perform action accordingly, and remove them when they become irrelevant.
This document guides the developer to find the traceability between UI and the respective controller components. The provided technical classes are available in the package of 'registration-client' module. In this module, the required controllers are bind with the FXML screens.
It doesn't detail about each methods level information since that is covered in Javadoc of each component and Design Documents.
Functionality:
Login with UserName and Password/ OTP/ BIO
Technical Detail:
Login screen with User ID will be loaded initially and after successful valudation of the user id the respective authenitcaiton screen [if multi-factor more than one authenticaiton] will be loaded
FXML and Controller class
RegistrtaionLogin.fxml --> LoginController.java and Authentication.fxml --> AuthenticationController.java. For each controller always the initialization() method will be called from the controller to initialize the screen
Input parameter:
The required buttons,text fields, Radio buttons, On-click events directly mapped to the Controllers of public methods
Functionality:
Officer Information Header Screen
Technical Detail:
After successful login, the Home screen displayed with the officer's information as a header.
FXML and Controller class
Header.fxml --> HeaderController.java. For each controller always the initialization() method will be called from the controller to initialize the screen
Input parameter:
The required buttons, text fields, Radio buttons, On-click events directly mapped to the Controllers of public methods.
Functionality:
Main / Home Screen
Technical Detail:
After successful login to the application, the application launches the home screen where the operator can do the new registration/UIN update/ Lost UIN / Pending Approval/ Update operator Bio-metrics operations
FXML and Controller class
RegistrationOfficerLayout.fxml, RegistrationOfficerPacketLayout.fxml --> PacketHandlerController.java. For each controller always the initalization() method will be called from the controller to initialize the screen
Input parameter:
The required buttons, text fields, Radio buttons, On-click events directly mapped ot the Controllers of public methods.
Functionality:
Registration Header Screen
Technical Detail:
On Click of any registration/UIN update or Lost UIN the screen header loaded with Registration Header screen, which indicates to the operator currently which data are we going to capture. It highlights with bold color.
FXML and Controller class
RegistrationHeader.fxml --> RegistrationHeaderController.java. For each controller always the initialization() method will be called from the controller to initialize the screen
Input parameter:
The required buttons, text fields, Radio buttons, On-click events directly mapped to the Controllers of the public methods
Functionality:
Demographic Screen
Technical Detail:
This screen helps to capture the demographic information of the Resident like Name,Age/DOB , Address, Parent/Guardian Details,Email ID and Mobile Number
FXML and Controller class
Registration.fxml, DemographicDetail.fxml --> RegistrationController.java. For each controller always the initialization() method will be called from the controller to initialize the screen
Input parameter:
The required buttons, text fields, Radio buttons, On-click events directly mapped to the Controllers of the public methods
Functionality:
Fingerprint Capture Screen
Technical Detail:
This screen helps to capture the fingerprint information of the Resident like left slap /Right Slap and two thumbs. Apart from this capture of single fingerprint for the authentication will also be called from here. The operations like Reset/Star Over and Scan methods are applicable to this screen
FXML and Controller class
FingerPrintCapture.fxml --> FingerPrintCaptureController.java. For each controller always the initialization() method will be called from the controller to initialize the screen
Input parameter:
The required buttons, text fields, Radio buttons, On-click events directly mapped to the Controllers of the public methods
Functionality:
Iris Capture Screen
Technical Detail:
This screen helps to capture the Iris information of the Resident like left Eye /Right eye. Apart from this capture of single iris for the authentication will also be called from here. The operations like Reset/Star Over and Scan methods are applicable to this screen
FXML and Controller class
IrisCapture.fxml --> IrisCaptureController.java. For each controller always the initialization() method will be called from the controller to initialize the screen
Input parameter:
The required buttons, text fields, Radio buttons, On-click events directly mapped to the Controllers of the public methods
Functionality:
Face Capture and Camera popup Screen
Technical Detail:
This screen helps to capture the Face information of the Resident using the ICFO standard. Apart from this capture of face for the authentication will also be called from here. The operations like capture/reset/close methods are applicable to this screen. The pop for the camera will be also part of this controller.
FXML and Controller class
FaceCapture.fxml --> FaceCaptureController.java and WebCamera.fxml --> WebCameraController.java. For each controller always the initialization() method will be called from the controller to initialize the screen
Input parameter:
The required buttons, text fields, Radio buttons, On-click events directly mapped to the Controllers of the public methods
Functionality:
Resident capture information Preview Screen
Technical Detail:
This screen helps to preview the captured information of the Resident like Demographic/Bio-metric and Documents scanned. This screen helps to edit the particular section of which we captured.
FXML and Controller class
RegistrationPreview.fxml --> RegistrationPreviewController.java. For each controller always the initialization() method will be called from the controller to initialize the screen
Input parameter:
The required buttons, text fields, Radio buttons, On-click events directly mapped to the Controllers of the public methods
Functionality:
Officer/Supervisor Authentication Screen
Technical Detail:
This screen helps to authenticate the officer/supervisor, after capture the all resident information. The authentication can happen base don the configuration like PWD/OTP/Bio-metric.
FXML and Controller class
OperatorAuthentication.fxml --> AuthenticationController.java. For each controller always the initialization() method will be called from the controller to initialize the screen
Input parameter:
The required buttons, text fields, Radio buttons, On-click events directly mapped to the Controllers of the public methods
Functionality:
Acknowledgment Screen
Technical Detail:
This screen helps to provide the acknowledgment information of the information captured of the resident. This helps the operator to print the acknowledgment slip and give to the resident.
FXML and Controller class
AckReceipt.fxml --> AckReceiptController.java. For each controller always the initialization() method will be called from the controller to initialize the screen
Input parameter:
The required buttons, text fields, Radio buttons, On-click events directly mapped to the Controllers of the public methods
Functionality:
Document Scan Screen & Scan Popup screen
Technical Detail:
This screen helps to scan the required documents which required based on the operations like New Registration/UIN update /Lost UIN. This scan/edit/remove operation of the documents mapped to this controller. For each scan button, the relevant scan pop window will be displayed. The operations capture will be part of the ScanPopupViewController.
FXML and Controller class
DocumentScan.fxml --> DocumentScanController.java and Scan.fxml --> ScanPopUpViewController.java. For each controller always the initialization() method will be called from the controller to initialize the screen
Input parameter:
The required buttons, text fields, Radio buttons, On-click events directly mapped to the Controllers of the public methods
Functionality:
Bio-metric Exception Screen
Technical Detail:
This screen helps to mark the bio-metrics which are not available for the resident while capturing the biometric information. By this screen, we can select/deselect the fingers [10] and iris[2]. The operation select/deselect mapped to the controller.
FXML and Controller class
BiometricException.fxml --> BiometricExceptionController.java. For each controller always the initialization() method will be called from the controller to initialize the screen
Input parameter:
The required buttons, text fields, Radio buttons, On-click events directly mapped to the Controllers of the public methods
Functionality:
Parent/Guardian Bio-metric Screen
Technical Detail:
This screen helps to capture the anyone of the parent bio-metric for the child registration/UIN update or Lost UIN. This screen provided with the dropdown by selecting the required bio-metric the same thing should be captured by the operator. The operation Reset/StarOver/Scan mapped to the controller.
FXML and Controller class
GuardianBiometrics.fxml --> GuardianBiometricsController.java. For each controller always the initialization() method will be called from the controller to initialize the screen
Input parameter:
The required buttons, text fields, Radio buttons, On-click events directly mapped to the Controllers of the public methods
Functionality:
Officer/Supervisor Onboarding Screen
Technical Detail:
This screen helps to Onboard the officer/supervisor to the current machine to create the New Registration/UIN Update and Lost UIN for the residents.
FXML and Controller class
Onboard.fxml, UserOnboard.fxml --> UserOnboardParentController.java. For each controller always the initialization() method will be called from the controller to initialize the screen
Input parameter:
The required buttons, text fields, Radio buttons, On-click events directly mapped to the Controllers of the public methods
Functionality:
Officer/Supervisor Fingerprint Capture Screen
Technical Detail:
This screen helps to capture the Officer/Supervisor fingerprint information of the Resident like left slap /Right Slap and two thumbs. Apart from this capture of single fingerprint for the authentication will also be called from here. The operations like Reset/Star Over and Scan methods are applicable to this screen
FXML and Controller class
UserOnboardFPCapture.fxml --> FingerPrintCaptureController.java. For each controller always the initialization() method will be called from the controller to initialize the screen
Input parameter:
The required buttons, text fields, Radio buttons, On-click events directly mapped to the Controllers of the public methods
Functionality:
Officer/Supervisor Iris Capture Screen
Technical Detail:
This screen helps to capture the Officer/Supervisor Iris information of the Resident like left Eye /Right eye. Apart from this capture of single iris for the authentication will also be called from here. The operations like Reset/Star Over and Scan methods are applicable to this screen
FXML and Controller class
UserOnboardIrisCapture.fxml --> IrisCaptureController.java. For each controller always the initialization() method will be called from the controller to initialize the screen
Input parameter:
The required buttons, text fields, Radio buttons, On-click events directly mapped to the Controllers of the public methods
Functionality:
Officer/Supervisor Face Capture and Camera popup Screen
Technical Detail:
This screen helps to capture the Officer/Supervisor Face information of the Resident using the ICFO standard. Apart from this capture of face for the authentication will also be called from here. The operations like capture/reset/close methods are applicable to this screen. The pop for the camera will be also part of this controller.
FXML and Controller class
UserOnboardWebCamera.fxml --> FaceCaptureController.java and WebCamera.fxml --> WebCameraController.java. For each controller always the initialization() method will be called from the controller to initialize the screen
Input parameter:
The required buttons, text fields, Radio buttons, On-click events directly mapped to the Controllers of the public methods
Functionality:
Pending Approval Screen
Technical Detail:
This screen helps the supervisor to approve the registration done by the officer. This screen displays the list of the packets with respect to their acknowledgment slip. The operations approve/reject mapped to this controller.
FXML and Controller class
RegistrationPendingApproval.fxml --> RegistrationApprovalController.java. For each controller always the initialization() method will be called from the controller to initialize the screen
Input parameter:
The required buttons, text fields, Radio buttons, On-click events directly mapped to the Controllers of the public methods.
Functionality:
Pending Approval - Rejection list Screen
Technical Detail:
This screen helps the supervisor to reject the registrations done by the officer. This screen displays the list of the packets with respect to their acknowledgment slip. The operations reject mapped to this controller. On selecting the rejection the drop-down will be displayed with a list of reasons to reject the registrations.
FXML and Controller class
RejectionComment.fxml --> RejectionController.java. For each controller always the initialization() method will be called from the controller to initialize the screen
Input parameter:
The required buttons, text fields, Radio buttons, On-click events directly mapped to the Controllers of the public methods.
Functionality:
Send Notification[SMS/Email] Screen
Technical Detail:
This screen helps the officer to send the SMS/email to other members. After successful registration of the resident, if the person wants to send the message to more than one person they can send by using this screen.
FXML and Controller class
SendNotification.fxml --> SendNotificationController.java. For each controller always the initialization() method will be called from the controller to initialize the screen
Input parameter:
The required buttons, text fields, Radio buttons, On-click events directly mapped to the Controllers of the public methods.
Functionality:
UIN - Update Selection Screen
Technical Detail:
This screen helps the officer to select the required fields to be updated as part of the UIN update screen. W.r.t the selection of the relevant fields and screen will be displayed subsequently.
FXML and Controller class
UpdateUIN.fxml --> UpdateUINController.java. For each controller always the initialization() method will be called from the controller to initialize the screen
Input parameter:
The required buttons, text fields, Radio buttons, On-click events directly mapped to the Controllers of the public methods.
Functionality:
Re-Registration Screen
Technical Detail:
This screen helps the officer to inform/not inform the re-registration status, which comes from the server as response.
FXML and Controller class
ReRegistration.fxml --> ReRegistrationController.java. For each controller always the initialization() method will be called from the controller to initialize the screen
Input parameter:
The required buttons, text fields, Radio buttons, On-click events directly mapped to the Controllers of the public methods.
Functionality:
Sync Data Screen
Technical Detail:
This screen helps the officer to sync the all required operations manually. Which is available at the Main home screen.
FXML and Controller class
SyncDataProcess.fxml --> SyncDataProcessController.java. For each controller always the initialization() method will be called from the controller to initialize the screen
Input parameter:
The required buttons, text fields, Radio buttons, On-click events directly mapped to the Controllers of the public methods.
This document guide the developer to find the traceability between functionality and the respective technical component. The provided technical classes are available in the package of 'registration-service' module. In this module the required functions are exposed as public method and that can be used to obtain the required features.
It doesn't detail about each methods level information since that are covered in Javadoc of each component.
Functionality:
Login with UserName and Password/ OTP/ BIO
Technical Detail:
Post successful login, session context would be created. That will be used throughout the application at the required places. The user detail and the respective roles are encapsulated inside the context. Without creation of this context object, the packet can't be created.
Main Service class and method:
SessionContext.create(UserDTO userDTO, String loginMethod, boolean isInitialSetUp, boolean isUserNewToMachine, AuthenticationValidatorDTO authenticationValidatorDTO)
Input parameter:
UserDTO – It should contain info of id, name, roles, center-id. loginMethod – possible values are PWD, OTP, FINGERPRINT, FACE, IRIS. isInitialSetUp – true/false, isUserNewToMachine – true/false, AuthenticationValidatorDTO – should contain id, password, otp
Auth:
Not required.
External Connectivity:
Service and DB
Functionality:
Packet Creation - New Registration / Update UIN/ Lost UIN
Technical Detail:
Based on the business need [New Registration / Update UIN/ Lost UIN] this 'RegistrationDTO' object should be populated with the relevant data and also pass the 'RegistrationMetaDataDTO.RegistrationCategory' as [New/ Update/ Lost].
Main Service class and methods
PacketHandlerService.handle(RegistrationDTO registrationDTO)
Input Parameter:
The RegistrationDTO object contains the RID, PRID, registration details of the individual and also contains the officer and supervisor details. This object has the following sub-classes: a. DemographicDTO - Details of the Demographic and Documents, b. BiometricDTO - Biometrics (Fingerprints, Irises, Face and Exception Face) of the individual, parent (or guardian), officer and supervisor, c. RegistrationMetaDataDTO - Metadata related to registration and d. OSIDataDTO - Details of the officer and supervisor who had authenticated the registration.
Auth:
SessionContext is required for creating the packet
External Connectivity
DB, File system
New Registration - Adult
As part of New registration, individual's Demographic, documents[POI and POA] and bio-metric [fingerprint, iris and face] will be captured. If an exception of the bio-metrics is marked, then exception photo will be captured.
New Registration - Child
As part of New registration, individual's Demographic, documents [POI, POA and POR] and anyone of parent's bio-metric [fingerprint/iris/face(if all fingerprint and iris are marked as exception)] along with that Parent's/Guardian's RID/UIN will be captured. If an exception is marked for the parent bio-metrics, an exception photo will be captured for the parent
UIN Update - Adult
As part of UIN Update, individual's will have the option to select the field that would like to update. For Demographic update --> UIN number, Name, Document[only if Name/Address is selected then POI for name and POA for address is mandate], and anyone of the bio-metric will be captured as a mandatory values. For Bio-metric update --> UIN number, Name and Bio-metrics [fingerprint, iris and face] will be captured, if an exception marked then exception photo will be captured
UIN Update-Child
As part of UIN Update, individual's will have the option to select which one they are going to be update. For Demographic update --> UIN Number, Name,POR document along with that Parent/Guardian Name and UIN along with anyone parent bio-metric should be captured; if any exception marked then the exception photo of the Parent/Guardian will be captured.
Lost UIN-Adult
As part of Lost UIN, an individual's all Bio-metrics[fingerprints, iris, and face] will be mandatory to find the lost UIN.
Lost UIN-Child
As part of Lost UIN, Parent/Guardian Bio-metric will be mandatory to find the lost UIN of the child. if an exception marked then the exception photo of the parent/Guardian will be captured.
Functionality:
PACKET SYNC– Sync all the Approved/ Rejected/ Re-Register Approved packets before Uploading to server
Main Service class and method:
PacketSyncServiceImpl.java - packetSync(List packetsToBeSynced)
Input Parameter:
packetsToBeSynced – The packet details which needs to be Synced.
Auth:
Authentication token required.
External Connectivity:
Packet Sync service REST call
Functionality:
Packet Upload
Main Service class and method:
PacketUploadService.pushPacket(File packet)
Input Parameter:
File object, which contains the packet to be uploaded.
Auth:
Authentication token required while doing file upload. Based on the SessionContext object the advice would attach the token and invoke the required service call.
External Connectivity:
Service, DB, File system
Functionality:
Packet Export
Main Service class and method:
PacketExportService.getSyncedRecords() - to fetch the packet to be exported. updateRegistrationStatus(List exportedPackets) - update the status once exported.
Input Parameter:
List of packet object.
Auth:
No.
External Connectivity:
DB, File system
Functionality:
Download Pre-Registration data during New Registration
Technical Detail:
The user provided pre-registration packet id related [demo/ doc] detail would be downloaded from Pre-registration DB using the respective REST service. After downloading the packet, the data would be mapped to the UI object and render the same to UI to display in the screen.
Main Service class and method:
PreRegistrationDataSyncServiceImpl.java - getPreRegistration(String preRegistrationId)
Input Parameter:
preRegistrationId- The pre reg id
Auth:
Authentication token required while downloading the packets. Based on the SessionContext object the advice would attach the token and invoke the required service call.
External Connectivity:
Pre Reg service REST call
Functionality:
EOD APPROVAL – Approve/Reject all the created packets
Main Service class and method:
RegistrationApprovalServiceImpl.java - updateRegistration(String registrationID, String statusComments, String clientStatusCode)
Input Parameter:
registrationID – The registration id of the packet that needs to be updated, statusComments - The comment status that needs to be updated for the given registration id of the packet, clientStatusCode - The status code that needs to be updated for the given registration id of the packet.
Auth:
NA
External Connectivity:
DB
Functionality:
Sync Data from Server to Client and Vice Versa.
Technical Detail:
This functionality will be executed as specified as sync-frequency in local DB. During start of the application, the scheduler would be loaded with the jobs configured in db and trigger the job. The scheduler would trigger the jobs at the configured frequency. While running the jobs, based on the functionality it would invoke the respective services and invoke the required external services to sync the data from server to client and vice versa. Post completion or every state of the job execution, the status would be updated in local db.
Main Service class and methods
Input Parameter:
-
Auth:
Auth token required for external services. This would be automatically taken care within this method. Nothing explicitly to be passed.
External Connectivity:
REST API calls, DB
Functionality:
MDM Integration – Register Device
Technical Detail:
This method automatically scans all devices by connecting to the MDM service, which is running in a particular port and stores it in device registry.
Main Service class and method:
MosipBioDeviceManager - init()
Input Parameter:
No parameter needed.
Auth:
Not required
External Connectivity:
deviceInfo - MDM service REST call
Functionality:
MDM Integration -Capture bio-metric
Main Service class and method:
BioServiceImpl - getFingerPrintImageAsDTOWithMdm(FingerprintDetailsDTO fpDetailsDTO, String fingerType)
Input Parameter:
FingerprintDetailsDTO – dto contains the finger print related details, fingerType – Type of the device like Fingerprint/ Iris/Face etc
Auth:
Not required
External Connectivity:
Capture - MDM service REST call
Functionality:
MDM Integration - Validate bio-metric against the bio value already captured and stored in Database.
Main Service class and method:
BioServiceImpl - validateFingerPrint(String userId) - based on provided user Id the relevant bio information would be fetched from database and same would be validated against the bio data received from MDM service.
Input Parameter:
mosipBioDeviceManager – scan(String deviceType)
Auth:
Not required
External Connectivity:
DB, Capture - MDM service REST call
Functionality:
MDM Integration - Display video stream
Main Service class and method:
Yet to be implemented
Input Parameter:
Auth:
Not required
External Connectivity:
Functionality:
TPM Public Key Sync
Technical Detail:
This service will be executed during initial set-up of registration client application. This service gets the Public Part of the Key used for signing from the TPM. Uploads this public key along with the machine name to the server. This service returns the key index which will be used for Master Sync Service
Main Service class and method:
TPMPublicKeySyncService.syncTPMPublicKey()
Input Parameter:
NA
Auth:
TPM 2.0 is required for this service
External Connectivity:
TPM, Web Service
The packets are created during individual registration process are structured and secured. The detail of the same can be found in this link.
List of packet status maintained in client db while moving the packet to the different state before and after pushing to the server.
Packet Status Desc
Status in Client
Once Packet Created
REGISTERED
Packet Approved
APPROVED
'Re-Register' packet approved
RE_REGISTER_APPROVED
Packet Rejected
REJECTED
Packet IDs Synced with Server
SYNCED
Packet pushed to Server
PUSHED
Packet exported to device
EXPORTED
Packet Status Desc
Status from Server
Packet in processing state
PROCESSING
UIN generated for the packet
PROCESSED
Unable to process the packet.
REREGISTER
Failed while processing packet due to internal issue
RESEND
Packet is received but not uploaded in LANDING_ZONE
RECEIVED
Duplicate found in abis
REJECTED
Below provided jobs are executed in batch mode through spring batch. The job execution frequencies are mentioned in the DB job related table. These jobs can also be triggered through manual process using 'Sync' option in the Menu, During initial login after successful online authentication and While starting the application if initial sync already completed.
Sl.No:
Service Desc.
Dependent Module
Under 'Sync' Menu
Initial Login
Application Launch
1.
Pre-registration Data Sync
Pre-reg
Y
N
N
2.
Policy Sync
Kernel
Y
N
N
3.
Registration Client Config Sync
Kernel
Y
Y
Y
4.
Registration Packet Status Reader
Reg-Proc
Y
N
N
5.
User Detail/Role Setup Sync
Kernel
Y
Y
Y
6.
Pre Registration Packet Deletion Job
local job
N
N
N
7.
Registration Packet Deletion Job
Local Job
N
N
N
8.
User Machine Mapping Sync Job
Kernel
Y
N
N
9.
Audit Log Deletion Job
Local Job
N
N
N
10.
Registration Packet Sync
Reg-Proc
Y
N
N
11.
Registration Packet Virus Scan
Reg-Proc
N
N
N
12.
Public key Sync service
Kernel
Y
Y
Y
13.
User Salt Sync service
Kernel
Y
Y
Y
As 'configurability' is the one of the major NFR being considered while designing the application, here listed out the required files where the configurations can be modified that will get reflected in application during runtime.
'registration-qa.properties' - Registration application specific configuration.
'application-qa.properties' - Overall application level common configuration.
These configuration would be downloaded to the client machine through the 'config' sync service. If there is any change with respect to 'kernel' properties then after downloading the properties the application will ask for 'restart'.
Age configuration:
Age limit is configurable in the application. User should modify the max age limit in both 'application' and 'registration' properties file.
{application property key : 'mosip.id.validation.identity.age'}
{registration property key : 'mosip.registration.max_age'}
Below find the list of tables used in Registration client application. Based on use cases, the table data gets updated during either sync process or transaction in local machine. There are few jobs are configured to clean the transactions histories from local tables and also pushing the audit data to server.
Sl. No
Table Name
Description
Source
1.
biometric_attribute
It contains the list of biometric attribute description[left slap, right iris..] for each biometric type [Fingerprint, Iris, Photo] with respect to language code
sync from server master table
2.
biometric_type
It contains the list of biometric type[Fingerprint, Iris, Photo] while respect to language code
Sync from server master table
3.
blacklisted_words
It contains the list of words which were not allowed during Registration process with respect to language code
Sync from server master table
4.
device_master
It contains master information related to device with respect to language code
Sync from server master table
5.
device_spec
It contains device specifications like brand, model with respect to language code
Sync from server master table
6.
device_type
It contains types of devices[Fingerprint scanner, camera] and their description with respect to language code
Sync from server master table
7.
doc_category
It contains list of document categories[Proof Of Address, Proof Of Identity...] which will be displayed in UI with respect to language code
Sync from server master table
8.
doc_type
It contains list of document types that are allowed for uploading documents in Registration with respect to language code
Sync from server master table
9.
gender
It contains list of gender types that are being used in Registration with respect to language code
Sync from server master table
10.
id_type
It contains list of Id types [Registration Id, Pre Registration Id] that are being used in Registration with respect to language code
Sync from server master table
11.
language
It contains list of languages that are being used in Registration
Sync from server master table
12.
location
It contains list of locations that are being used in Registration with respect to language code
Sync from server master table
13.
machine_master
It contains list of machine related data[mac address, serial number, machine name...] with respect to language code
Sync from server master table
14.
machine_spec
It contains list of machine specifications[brand, model...] with respect to language code
Sync from server master table
15.
machine_type
It contains list of machine types[Desktop,Laptop...] with respect to language code
Sync from server master table
16.
reason_category
It contains list of reason categories[Client Rejection, Manual Adjudication...] with respect to language code
Sync from server master table
17.
reason_list
It contains list of reasons [Invalid Address, Gender-Photo Mismatch...] that are listed during Registration Approval/Rejection with respect to language code
Sync from server master table
18.
registration_center
It contains list of Registration center ids with respect to language code
Sync from server master table
19.
reg_center_device
It contains list of Registration center ids with respect to language code
Sync from server master table
20.
reg_center_machine
It contains list of machine ids which are mapped to corresponding center id
Sync from server master table
21.
reg_center_machine_device
It is mapping table of center, machine and device
Sync from server master table.
22.
reg_center_type
It contains list of center types with respect to language code
Sync from server master table
23.
reg_center_user
It contains list of user ids that are mapped to corresponding center id
Sync from server master table
24.
reg_center_user_machine
It is a mapping table for center, user and machine
During Onboarding process
25.
template
It contains list of Templates that will be displayed during Registration with respect to language code
Sync from server master table
26.
template_type
It contains list of template types[email template, sms template..] with respect to language code
Sync from server master table
27.
title
It contains list of Titles[Mr, Mrs..] with respect to language code
Sync from server master table
28.
valid_document
It contains list of valid documents allowed for Registration with respect to language code
Sync from server master table
29.
sync_job_def
It contains list of Job details[Master Sync, User Detail Sync..] that are required for sync
Sync from server master table
30.
screen_authorization
It contains list of Screen Ids which are required for accessing features[New Registration, EOD..] with respect to roles
Sync from server master table
31.
role_list
It contains list of roles[Registration Officer, Registration Supervisor..] referred in Registration
Sync from server master table
32.
process_list
It contains list of process[login, eod..] happen during registration
Sync from server master table
33.
app_authentication_method
It contains list if authentication methods[PWD, OTP..] with respect to roles and process[login, eod..]
Sync from server master table
34.
app_detail
It contains list of application details[Pre-Registration, Registration Client] with respect to language code
Sync from server master table
35.
app_role_priority
It contains list of role priority details with respect to Process[login, eod..] and roles
Sync from server master table
36.
GLOBAL_PARAM
It contains list of Configuration related details used in Registration application.
Sync from server configuration [registration.properties, application.properties]
37.
user_detail
It contains list of User details[id,name, email..]
Sync from server master table
38.
user_pwd
It contains User Password details
Sync from server master table
39.
user_role
It contains data of roles which were mapped to the user
Sync from server master table
40.
user_biometric
It contains User biometrics[Fingerprint, Iris..] details[minutia, biometric type..]
During Onboarding Process
41.
key_store
It contains Mosip Public key , Packet creation key
During Public key Sync and Policy sync
42.
sync_control
It contains information about the jobs which are executed successfully along with its last time stamp
During Manual Sync and Scheduled Jobs
43.
sync_transaction
It contains data about all sync transactions
During Manual Sync and Scheduled Jobs
44.
registration
It contains data about Registration Packet[Registration Id, Status..]
During Registration process
45.
registration_transaction
It contains data of all transactions during registration process
During Registration process
46.
pre_registration_list
It contains list of Pre Registration details[Pre Registration Id, Status..]
During Pre Registration Sync
47.
audit_log_control
It contains data of Audit logging[From Time, To Time..]
During local transaction.
The UI specific labels and messages are maintained in the language specific property file. Based on the primary and secondary language the respective bundle would be loaded during runtime and displayed in the screen.
messages_en.properties - Messages are in English language. messages_ar.properties - Messages are in Arabic language. messages_fr.properties - Messages are in French language. labels_en.properties - Labels are in English language. labels_ar.properties - Labels are in Arabic language. labels_fn.properties - Labels are in French language.
Below find the list of error code and description which are thrown from application during the process.
Class Name
Error Codes
Description
GPSFacade
REG-LGE-002
GPS signal is weak please capture again
SyncStatusValidatorService
REG-ICS-006
GPS signal is weak please capture again
SyncStatusValidatorService
REG-ICS-005
GPS device not found. Please connect an on-boarded GPS device.
SyncStatusValidatorService
REG-ICS-005
Please connect the GPS Device
SyncStatusValidatorService
REG-ICS-004
Please insert the GPS device in the Specified Port
RegistrationApprovalController
LGN-UI-SHE
IO Exception
PacketSynchService
REG-PSS
Unable to Sync Packets to the server
PacketUploadService
REG-PUS
Unable to Push Packets to the server
BioService
IRC-IFC
Exception while scanning iris of the individual
BioService
FPC-FCS
Exception while scanning fingerprints of the individual
RestClientAuthAdvice
REG-RCA
Exception while adding authorization token to web-service request
TPMUtil
TPM-UTL-001
Exception while signing the data using TPM
TPMUtil
TPM-UTL-002
Exception while validating the signature provided by TPM
TPMUtil
TPM-UTL-003
Exception while encrypting the data using asymmetric crypto-algorithm through TPM
TPMUtil
TPM-UTL-004
Exception while encrypting the data using asymmetric crypto-algorithm through TPM
TPMUtil
TPM-UTL-005
Exception while getting the public part of the TPM signing key
TPMUtil
TPM-UTL-006
Exception while getting the TPM instance
TPMUtil
TPM-UTL-007
Exception while closing the TPM instance
TPMUtil
TPM-INT-001
Exception while closing the TPM instance
RegIdObjectValidator
REG-IOS-001
Invalid ID Object Schema
RegIdObjectValidator
REG-IOS-002
Invalid ID Object Pattern
RegIdObjectValidator
REG-IOS-003
Invalid Master Data Object Pattern
RestClientAuthAdvice
REG-RCA-001
Generic Exception reported by server, while invoking web-service.
RestClientAuthAdvice
REG-RCA-002
Exception while generating the signature of request body
RestClientAuthAdvice
REG-SDU-004
Response header received from the web-service is not as expected
DemographicDetailController
KER-IDV-102
PRID should not contain any sequential and repeated block of number for 2 or more than two digits
UpdateUINController
KER-IDV-203
UIN length should be as per configured digit.
RegistrationController
KER-TRL-002
Language code not supported
DemographicDetailController
KER-IDV-103
PRID length should be as configured digit
RestClientUtil
RPR-PKR-009
Packet HashSequence did not match
find_sec_bugs
Scans source code for vulnerable code, Has the abilty to integrate into developer machine. Effective with Java
SAST
Open Source
Yes
A SASS based source code review platform. Its free for open source projects. Can do both Java and javascript
SAST
Free
Yes
OWASP Zap proxy
This is the best we have and we should use the ZAP and automate all tests
DAST
Open Source
Yes
MS Baseline security Analyzer
In case we use a windows infrastructure then this tool is usefull.
Hardening
Free
No
Open Scap
We will need to create a custom profile and should be able to scan for hardened OS
Hardening
Free
Yes
Open Scap
Docker scanning
Docker scan
Free
Yes
Nessus Vulnerability Scanner
Vulnerability Scanning
Vulnerability Scanning
Commercial
No
Kali linux
OS with all the necessary tools to perform a pentest. This would be a lab setup and would be used as part of UAT testing
Penetration Testing
Open Source
No
Skipfish
Hacking tool set from google.
DAST
Open Source
No
Burp suite
A web proxy used for penetration testing of web applications
DAST
Commercial
No
Courtesy : Sasikumar Ganesan
JobConfigurationServiceImpl.executeAllJobs() - This would load all the active jobs from the local db and trigger the jobs.