Tech Debt aka technical debt is part of the software engineering development process. This is also known as Code debt sometimes. The immediate question that pops up is all tech debt bad?
The simple answer to that question is – It depends.
Some tech debt is intentional and some is unintentional. As we explore this topic as part of the software engineering development process, it is necessary to understand every developer has to pay back the debt at some point in time.
What is Tech Debt?
Technical debt is a quick and dirty solution to a software problem. In many cases, to launch an MVP (minimum viable product), engineers come up with a quick solution. It’s not necessarily that a quick solution is bad. But if it is not thoroughly tested in real-world scenarios, it can cause some downstream effects. Is all technical debt bad? Technical debt gives a sense that it is bad. But it all depends on the scenario you are working on.
If you are implementing a solution quickly, it might align temporarily with the expectation, but might not always be right. This is where technical debt comes into the picture. Recognizing technical debt is necessary. Addressing the debt depends on the situation.
You can not prevent technical debt. In many cases, you do not have all the information when you are building a solution and you have to make assumptions.
Bad code is not necessarily a tech debt. But it can incur a cost in long term and that would end up being a tech debt.
Types of Tech Debt
Let’s look at different types of tech debts.
Intentional Tech Debt
To release a product to market early, many times engineers and stakeholders reduce the scope of the requirements. In many cases, everyone involved had to make choices, and that ends up causing an intentional tech debt. To get user feedback quickly, the product makes such a choice and accepts the fact the performance can be poor, the product can be unstable. There is an inherent risk involved with intentional tech debt.
Unintentional Tech Debt
On the other spectrum is unintentional tech debt. Most of this tech debt arises from the complexity of requirements and products. Product managers, domain experts, and engineers make assumptions in case of complexity. With unknowns involved, it becomes really hard to predict what can cause issues with the product. In such cases, engineering teams cut corners, and test the product insufficiently. If teams can recognize this debt, they can address it. Engineering teams have to adjust their development process to address this debt.
Environment Tech Debt
When engineers build a software product, it involves multiple third parties like libraries, other vendor products, or software. As time progresses, if engineers don’t keep the product up-to-date with various components, the product can start accruing an environmental tech debt. The most serious of tech debt in such cases can be a security threat. If engineers don’t patch libraries on time, security vulnerabilities can expose the product to risk. This kind of debt is recognizable over time and the teams involved need to remain on top.
The Effects of Tech Debt
There can be effects of tech debt both business-wise or financially.
Poor user experience
Security concerns and issues
Reduced time for feature development
Possible loss of customers
Lower productivity
Managing Tech Debt
As previously stated, engineers need to address tech debt at some point in time. How do you manage tech debt then?
Make time to address tech debt. Once tech debt is identified, engineering teams should make time to address tech debt to avoid the long-term effect.
Separate good debt and bad debt. Address bad debt sooner. Evaluate if good debt is to be kept in the system for a long.
Measure the impact of tech debt. If you can create performance metrics around tech debt, measure the performance. This gives clarity on how the debt is affecting and why it needs to be addressed.
Adopt the new processes and quality reviews to avoid future tech debt.
Conclusion
In this post, we talked about technical debt and the kind of impact it can create on user experience and business. As an engineer, it can take the experience to identify this debt. But always make sure to make time to address the tech debt.
If you want to learn more about how to implement two-factor authentication with spring security, here are my previous two posts
With security threats rising, it becomes important to secure accounts. In my previous post, I showed how to sign up for two-factor authentication with spring security.
In this post, I show how to log in with two-factor authentication with spring security. Before a user can log in, the user needs to register for the application. Assuming you followed my previous post, we have a user who has registered for multi-factor authentication (MFA).
User will access our application and if not logged in, will get redirected to the login page. The login page looks like below:
User will have to enter a username, password, and a token from the GoogleAuthenticator App for this particular application.
In a previous post, I assume you register the application with GoogleAuthenticator App.
On our login page, we pass an extra parameter of token to the backend to verify.
The architecture of the Login Process
To understand the entire login process with Spring Security, it is good to see the overall picture of this process.
As we know, Spring Security works with filter chains. One of the filters UsernamePasswordAuthenticationFilter is used in Username and Password authentication flow. In this login flow as well, our authentication starts with that filter. Once the user has entered credentials and the token, it will pass through that filter.
We will need to implement a UserDetailsService to fetch user. This service is part of AuthenticationManager that UsernamePasswordAuthenticationFilter provides.
This UserDetailsService will load the user as follows:
@Override
public UserDetails loadUserByUsername (String email) throws UsernameNotFoundException
{
final UserEntity customer = userRepository.findByEmail(email);
if (customer == null) {
throw new UsernameNotFoundException(email);
}
LOG.info("Getting User", customer);
CustomUser user = CustomUser.CustomUserBuilder.aCustomUser().
withUsername(customer.getEmail())
.withPassword(customer.getPassword())
.withAuthorities(getAuthorities(customer))
.withSecret(customer.getSecret())
.withAccountNonLocked(false)
.build();
return user;
}
Additionally, we call WebAuthenticationDetails implementation to build authentication details from the HttpServletRequest object. We will implement this interface with CustomWebAuthenticationDetails as follows:
public class CustomWebAuthenticationDetails extends WebAuthenticationDetails
{
private String token;
public CustomWebAuthenticationDetails (HttpServletRequest request)
{
super(request);
this.token = request.getParameter("customToken");
}
@Override
public String toString() {
return "CustomWebAuthenticationDetails{" +
"token='" + token + '\'' +
'}';
}
@Override
public boolean equals(Object o) {
if (this == o) return true;
if (o == null || getClass() != o.getClass()) return false;
if (!super.equals(o)) return false;
CustomWebAuthenticationDetails that = (CustomWebAuthenticationDetails) o;
return Objects.equals(token, that.token);
}
@Override
public int hashCode() {
return Objects.hash(super.hashCode(), token);
}
public String getToken() {
return token;
}
public void setToken(String token) {
this.token = token;
}
}
Furthermore, we fetched the customToken from our request and set in authentication details.
We have validated user credentials, fetched the user from the database, and also set the token. Moreover, all that is left is to validate if the token is still valid.
We implement a CustomAuthenticationProvider from DaoAuthenticationProvider to fetch user details and validate TOTP token. This looks like below:
MfaTokenManager calls TOTP library to verify the code. Nevertheless, take note that we are passing one time token along with the user secret that we created when the user registered for the application and scanned the QR Code.
If token validation is successful, SecurityConfiguration will proceed with calling CustomLoginSuccessHandler . This handler redirects the user with a right role to /home page.
This completes our two-factor authentication login flow with Spring Security.
In this post, I showed how to use Spring Security for the Two-Factor Authentication Login process. If you have feedback for this post, please post your comment.
This is a two-post series in which I will show how to implement two-factor authentication with Spring Security.
In this post, we will cover how to implement user registration for two-factor authentication. Sometimes two-factor authentication is also known as multi-factor authentication (MFA).
Previously, I have covered different Spring Security scenarios. If you want to start with the fundamentals, how spring security filter chain works is a good post to start with.
Two-Factor Authentication
With the advent of web applications, the security of applications and user data has become even more important. Back in the day, a simple username and password form was enough. But that was never secure enough. Adding an additional layer of security to a login form can dramatically improve the application’s security. Two-Factor authentication adds another layer for authentication. Overall, the user enters credentials and if that is validated, the user has to enter a time-based one-time password (TOTP).
Two-Factor authentication is two-step authentication. In the first step, user credentials are verified and in the next step, a one-time password is. How is this one password generated? How user can set up two-factor authentication? What is the password validity duration?
In this post, we will cover the details of the user registration process where a user can register for two-factor authentication.
User Flow for Two-Factor Authentication
As part of user registration, we will be following the user flow shown below.
The user accesses the application.
The application shows a login screen.
If a user is not signed up before, the user selects the registration option.
The user enters details and chooses to enable MFA (multi-factor authentication).
Spring Security (as part of our application) will show a QR Code screen.
Spring Security will assign that secret key (QR Code) to the user profile and store in DB.
The user scans QR Code on the Google Authenticator app.
That covers the registration flow. Let’s see how we implement this now.
Demo Application
To demonstrate two-factor authentication, we will create a demo application using Spring Boot and Spring Security. This will be a minimal application with a login screen, registration screen and a home screen.
1. Dependency Configuration
We will need some specific dependencies for our application to implement two-factor authentication.
This dependency provides us options to set up QR Code authentication, verify codes, and also recovery codes if you lose your phone for the authenticator app.
We are using spring-boot-starter-mail dependency to send confirmation emails when the user signs up. The rest of the dependencies are pretty common if you have built a spring boot application.
2. User Registration
Previously, I stated about the user registration flow. Now, we will implement a registration controller that takes the request from the client.
package com.betterjavacode.twofactorauthdemo.controllers;
import com.betterjavacode.twofactorauthdemo.dtos.MfaTokenDto;
import com.betterjavacode.twofactorauthdemo.dtos.UserDto;
import com.betterjavacode.twofactorauthdemo.exceptions.InvalidTokenException;
import com.betterjavacode.twofactorauthdemo.services.UserService;
import org.apache.commons.lang3.StringUtils;
import org.springframework.context.MessageSource;
import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.validation.BindingResult;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.servlet.mvc.support.RedirectAttributes;
import javax.annotation.Resource;
@Controller()
@RequestMapping("/register")
public class RegistrationController
{
private static final String REDIRECT_LOGIN= "redirect:/login";
@Resource
private UserService userService;
@Resource
private MessageSource messageSource;
@GetMapping
public String register(final Model model){
model.addAttribute("userData", new UserDto());
return "useraccount/register";
}
@PostMapping
public String userRegistration(final UserDto userData, final BindingResult bindingResult,
final Model model) {
if (bindingResult.hasErrors()) {
model.addAttribute("userData", userData);
return "useraccount/register";
}
try {
userService.register(userData);
MfaTokenDto mfaData = userService.mfaSetup(userData.getEmail());
model.addAttribute("qrCode", mfaData.getQrCode());
model.addAttribute("qrCodeKey", mfaData.getMfaCode());
model.addAttribute("qrCodeSetup", true);
} catch (Exception e) {
bindingResult.rejectValue("email", "userData.email","An account already exists for this email.");
model.addAttribute("userData", userData);
return "useraccount/register";
}
model.addAttribute("registrationMsg", "Thanks for your registration. We have sent a " +
"verification email. Please verify your account.Please scan the QR code for generating MFA token for login.");
return "useraccount/register";
}
@GetMapping("/verify")
public String verifyCustomer(@RequestParam(required = false) String token, final Model model, RedirectAttributes redirAttr){
if(StringUtils.isEmpty(token)){
redirAttr.addFlashAttribute("tokenError", "Token is empty");
return REDIRECT_LOGIN;
}
try {
userService.verifyUser(token);
} catch (InvalidTokenException e) {
redirAttr.addFlashAttribute("tokenError", "Token is invalid. Provide a valid token.");
return REDIRECT_LOGIN;
}
redirAttr.addFlashAttribute("verifiedAccountMsg", "Your account is verified. You can " +
"login now");
return REDIRECT_LOGIN;
}
}
You can see two methods in this controller. One is GET to show the registration page and the other one is POST to process form submission from the user.
We are using @Autowired User Service class UserService to register users and to set up MFA.
Let’s look at those methods.
@Override
public void register (UserDto user) throws UserAlreadyExistsException
{
if(checkIfUserExist(user.getEmail())){
throw new UserAlreadyExistsException("User already exists for this email");
}
UserEntity userEntity = new UserEntity();
BeanUtils.copyProperties(user, userEntity);
encodePassword(user, userEntity);
userEntity.setSecret(mfaTokenManager.generateSecretKey());
userEntity.setMfaEnabled(true);
userRepository.save(userEntity);
sendRegistrationConfirmationEmail(userEntity);
}
Here, we throw an exception for user already exists if user is already registered. We save user information with userEntity and assign a secret key (QR Code) for this user. Each user will receive a unique QR Code. This allows linking the user profile with the secret key. We will use this secret key during authentication code verification and I will show this in the next post.
Once the user is created, we send a confirmation email for the user to verify. That’s why we have /verify method in RegistrationController.
As part of registration, we also set up MFA.
@Override
public MfaTokenDto mfaSetup (String email) throws UnknownIdentifierException,
QrGenerationException
{
UserEntity user= userRepository.findByEmail(email);
if(user == null ){
throw new UnknownIdentifierException("unable to find account or account is not active");
}
return new MfaTokenDto(mfaTokenManager.getQRCode( user.getSecret()), user.getSecret());
}
We use MFATokenManager to build a QR Code.
@Override
public String getQRCode (String secret) throws QrGenerationException
{
QrData data = new QrData.Builder().label("MFA")
.secret(secret)
.issuer("Two Factor Authentication Demo")
.algorithm(HashingAlgorithm.SHA256)
.digits(6)
.period(30)
.build();
return Utils.getDataUriForImage(
qrGenerator.generate(data),
qrGenerator.getImageMimeType()
);
}
Most of QrGeneration is using the totp library that we are using in this app.
3. Demo
So far, we have shown user registration through code. I have not covered everything in detail, but I will share my github repository with all the code to understand this. As part of demo, we will start the application and you will see the login screen as below:
User accessing the application for first time, will choose Register first time option.
Once the user enters details and submits the form for registration, the user will see a screen with QR Code for two-factor authentication.
Now, the user can scan the QR Code with Google/Authy Authenticator apps.
That’s all for user registration. When the next time, the user wants to login, they will have to provide TOTP code. We will see this in the next post.
Conclusion
In this post, I showed how to implement user registration for two-factor authentication.
If you are diving into Spring Security and want to learn more, here is my book Simplifying Spring Security which is on a Black-Friday sale currently.
In this post, I will cover different communication patterns between microservices. As microservices have become more industry pattern, it has also become important how these microservices communicate with each other.
The most common pattern for communication has been synchronous REST API calls. But this pattern comes with its own set of trade-offs. Another pattern is asynchronous communication. Let’s dive deeper into these patterns.
Synchronous Calls
The most standard way for services to communicate between themselves is through HTTP synchronous calls. One source service calls a target service. Target service returns with a response that the source service uses for further processing.
In many web applications, a client (front end) calls a backend service (microservice) to fetch or create data.
Similarly, two microservices can communicate with each other through HTTP. Most frameworks provide an HTTP library that allows one service to call another service. For Example – Axios or Feign.
Challenges with Synchronous Communication
Timeout
If service A calls service B to fetch data, but service B takes forever to respond, service A can time out. What happens if the call is going to cause some side-effect on the service B side? In that scenario, there will be data inconsistencies between both services.
Strong coupling
Synchronous communication between services can create strong coupling between services and can be detrimental to microservice architecture overall. Loose coupling was one of the main features of microservices. If any of the services are down, the dependent services might not work the way they were intended.
With event-driven architecture, asynchronous communication has become more popular. One service publishes a message and another service consumes that message. This does not necessarily happen in real-time. Service A publishes a message and still continues to function without knowing in that moment if other services have consumed that message. Consumer services consume the earlier published message when they are ready.
Usually, these services use message-broker to publish and consume the message from. These services may not know each other and offer the advantage of loose coupling.
Another advantage of asynchronous calls is that the message broker offers a retry mechanism. In the scenario, the consumer did not receive the message, the message can be republished.
Challenges with Asynchronous Communication
Message broker
With asynchronous communication, we introduce a centralized entity message broker. If a message broker is down, there will not be any communication between services.
Schema changes
If the publishing service changes the message schema, it can break consumer service unless there is backward compatibility. This defeats the purpose of microservices which allow independent deployments.
Two-phase commit
Publisher service publishes the message as part of business logic. In most cases, it does this by first committing a transaction and then publishing a message. It must perform this action with two-phase commit. But for whatever reason, if the transaction fails and rolled back, then we are in soup since the message has already been published.
In such cases, it is best to avoid a two-phase commit and store the messages in a database on both sides publisher as well consumer.
When to use these patterns?
It’s not very clear when to use Synchronous or Asynchronous calls. When you start designing a system, you will have to make calls and take into account all the trade-offs. Irrespective of that, one can follow certain notions about when to use these patterns
If you want to query data from another service and want to use that data immediately, use Synchronous communication.
If a call to another service is allowed to fail and does not bring down the calling service or any dependent services, you can use Synchronous communication without any fancy retry mechanism.
If a service wants to change the state of certain business logic, in such a scenario, it can publish a message with an Asynchronous communication pattern.
Two services involved in a business logic do not need to perform the action immediately or do not depend on the results of the action.
Conclusion
In this post, I discussed the communication patterns of microservices. In synchronous communication patterns, one can use HTTP or gRPC protocols. In asynchronous communication patterns, one can use a message broker for publishing and subscribing to messages.
In this post, I will show how to implement basic authentication using Passport.js in a NestJS Application. So far in the NestJS series, we have covered
Basic authentication though not secure for production applications, has been an authentication strategy for a long time.
Usually, a user accesses the application and enters a username and password on the login screen. The backend server will verify the username and password to authenticate the user.
There are a few security concerns with basic authentication
Password entered is plain text. It all depends on how the backend is handling the verification of passwords as well as the storage of passwords. The recommended way is to store the hash of the password when the account is created. Hashing is a one-way mechanism. So we will never know user passwords and if a database is breached, we won’t be exposing passwords.
If we don’t use re-captcha mechanism, it is easy for attackers to attack with a DDOS attack.
Passport Library
We will use Passport library as part of this demo. Passport is authentication middleware for Node JS applications. NestJS Documentation also recommends using the passport library.
As part of using Passport library, you will implement an authentication strategy (local for basic authentication OR saml for SAML SSO).
In this implementation, we will implement a method validate to validate user credentials.
Let’s create a project for this demo and we will create two separate directories for frontend (ui) and backend.
Frontend application with React
In our ui directory, we will use reactjs framework to build the UI. If you are using react-scripts, we will start with
npx create-react-app ui
Create the login page
Once we have react app created, we have the bare bones of the app to make sure it is running. Now, we will add a login page where the user will enter credentials.
We will need two libraries in the login page Signin.js
axios to call backend API
useNavigation to navigate to different pages.
handleSubmit is a function that we will call when a user submits the form on the login screen.
Once the user submits the form, handleSubmit collects submitted data and calls backend API with that form data.
User sign up
The sign in page can be of less help if there is no for users to sign up. Of course, it all depends on your user flow.
On the user signup page, we will be asking for firstName, lastName, email and password. Similar to signin page, we will have a handleSubmit function that will submit the signup form. It will call the backend API for signup.
let navigate = useNavigate();
const handleSubmit = async (event) => {
event.preventDefault();
const data = new FormData(event.currentTarget);
console.log(data);
const form = {
firstName : data.get('fname'),
lastName: data.get('lname'),
email: data.get('email'),
password: data.get('password')
};
await axios.post("http://localhost:3000/api/v1/user/signup", form);
navigate('/')
};
We will call this function handleSubmit on the event call onSubmit
As far as the Home page is concerned, we have a simple home page that shows Welcome to Dashboard. The user will navigate to the home page if authenticated successfully.
Backend application with NestJS
Let’s look at the backend side of this application. I will not show the basics of creating a NestJS app and setting up Prisma as ORM. You can follow those details here .
We will create a user table as part of the Prisma setup.
// This is your Prisma schema file,
// learn more about it in the docs: https://pris.ly/d/prisma-schema
generator client {
provider = "prisma-client-js"
}
datasource db {
provider = "mysql"
url = env("DATABASE_URL")
}
model User {
id String @id @default(uuid())
email String @unique
first_name String
last_name String?
password String
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
}
When a user signs up for our application, we will store that information in User table.
Controller for backend APIs
We will need two APIs – one for signup and one for sign-in. We already showed in the frontend section about the sign-up page. When the user submits sign-up page, we will call sign-up API on the backend.
@Post('/signup')
async create(@Res() response, @Body() createUserDto: CreateUserDto) {
const user = await this.usersService.createUser(createUserDto);
return response.status(HttpStatus.CREATED).json({
user
});
}
The frontend will pass an object for CreateUserDto and our UsersService will use that DTO to create users with the help of a repository.
Controller -> Service -> Repository.
Service performs the business logic and the repository interacts with the database.
import { Injectable } from '@nestjs/common';
import { PrismaService } from 'src/common/prisma.service';
import { CreateUserDto } from './dtos/create-user.dto';
import * as bcrypt from 'bcryptjs';
import { UserRepository } from './user.repository';
import { User } from './entities/user.entity';
@Injectable()
export class UsersService {
constructor(private readonly prismaService: PrismaService, private readonly userRepository: UserRepository) {}
async createUser(user: CreateUserDto) {
const hashedPassword = await bcrypt.hash(user.password, 12);
const userToBeCreated = User.createNewUser({
firstName: user.firstName,
lastName: user.lastName,
email: user.email,
password: hashedPassword,
});
return await this.userRepository.save(userToBeCreated);
}
async findById(id: string) {
return await this.userRepository.findById(id);
}
async getByEmail(email: string) {
const user = await this.userRepository.findByEmail(email);
return user;
}
}
As you can see above, while creating a new user, we are storing the hash of the password in the database.
We will use a basic authentication mechanism for our application. Passport calls these mechanisms as strategies. So, we will be using the local strategy.
In NestJS application, we basically implement the local strategy by extending PassportStrategy.
import { Injectable, } from "@nestjs/common";
import { PassportStrategy } from '@nestjs/passport';
import { Strategy } from 'passport-local';
import { User } from "src/users/entities/user.entity";
import { AuthService } from "./auth.service";
@Injectable()
export class LocalStrategy extends PassportStrategy(Strategy) {
constructor(private readonly authService: AuthService) {
super({
usernameField: 'email'
});
}
async validate(email: string, password: string): Promise {
return this.authService.getAuthenticatedUser(email, password);
}
}
For the local strategy, passport calls validate the method with email and password as parameters. Eventually, we will also set up an Authentication Guard.
Validate method uses authService to get authenticated user. This looks like below:
import { HttpException, HttpStatus, Injectable } from '@nestjs/common';
import * as bcrypt from 'bcryptjs';
import { User } from 'src/users/entities/user.entity';
import { UsersService } from 'src/users/users.service';
@Injectable()
export class AuthService {
constructor(private readonly userService: UsersService) {}
async getAuthenticatedUser(email: string, password: string): Promise {
try {
const user = await this.userService.getByEmail(email);
console.log(user);
await this.validatePassword(password, user.password);
return user;
} catch (e) {
throw new HttpException('Invalid Credentials', HttpStatus.BAD_REQUEST);
}
}
async validatePassword(password: string, hashedPassword: string) {
const passwordMatched = await bcrypt.compare(
password,
hashedPassword,
);
if (!passwordMatched) {
throw new HttpException('Invalid Credentials', HttpStatus.BAD_REQUEST);
}
}
}
Passport provides in-built guard AuthGuard. Depending on what strategy you are using, we can extend this AuthGuard as below:
import { Injectable } from "@nestjs/common";
import { AuthGuard } from "@nestjs/passport";
@Injectable()
export class LocalAuthGuard extends AuthGuard('local') {
}
Now in our controller, we will use this guard for authentication purposes. Make sure you have set up your Authentication Module to provide LocalStrategy.
import { Module } from '@nestjs/common';
import { AuthService } from './auth.service';
import { AuthController } from './auth.controller';
import { UsersModule } from 'src/users/users.module';
import { PrismaModule } from 'src/common/prisma.module';
import { LocalStrategy } from './local.strategy';
import { PassportModule } from '@nestjs/passport';
@Module({
imports: [UsersModule, PrismaModule, PassportModule],
controllers: [AuthController],
providers: [AuthService, LocalStrategy]
})
export class AuthModule {}
In our User Controller, we have added @UseGuards(LocalAuthGuard).
Demonstration of Basic Authentication with Passport
We have covered the front end and backend. Let’s take a look at the actual demo of this application now.
Go to frontend directory and start our react app
npm start
It will run by default on port 3000, but I have set port 3001 to use.
start : set PORT=3001 && react-scripts start
Also start the backend NestJS app
npm run start
This will run by default on port 3000. I have not changed that and using the default port. The frontend will call backend APIs on port 3000. Of course, in real-world applications, you will have some middleware like a load balancer or gateway to route your API calls.
Once the applications are running, access the demo app at http://localhost:3001 and it should show the login screen.
If you don’t have a user, we will create a new user with sign-up option. Once the user enters credentials, user will see the home page
That’s all. The code for this demo is available here.
Conclusion
In this post, I showed the details of the Passport library and how you can use this library for basic authentication in a Nest JS and React application.
