How to create an orthodox mysterious NoClassDefFoundError

When I began my current job, I also began encountering NoClassDefFoundErrors in different places. At that time I had never seen them before, and for long I have been puzzled how they are created.

Now, I finally understood how to create it correctly. Enjoy :)

public class A {
   
    public static final A INSTANCE = new A();
   
    static {
        throwError();
    }
   
    private static void throwError() {
        throw new RuntimeException();
    }
}

public class T {
    static {
        try {
            A a = A.INSTANCE;
        }
        catch (Throwable t) {
            // IGNORE
        }
    }
   
    public static void main(String[] args) {
        new A();
    }
}

Kotlin is fun :-)

I have just recently began experimenting with language called Kotlin, which is a statically typed programming language compiled to JVM byte code.

I wanted to try how it works and how affects coding style. So far, my personal feeling is that Kotlin combines very well statically typed paradigm and the flexibility of Javascript.

 I also wanted to try how Context works with Kotlin and so far everything has worked as expected. At this moment, Kotlin is still under development and has for instance incomplete support for method parameter annotations. This creates some inconveniences with Guice-related injections, but that is a minor concern.

One really nice feature in Kotlin is its null-safety. Basically it means that in common cases possible null-pointer references are forbidden at compile time. Code does not compile if null-checks aren't properly handled. And in case where null pointer might occur, you as a developer has to choose how to deal with it. For me there has been a certain learning curve and especially when Kotlin-code is mixed with Java-code it may be confusing sometimes, because Kotlin assumes that Java-classes are not null-safe.

I have also experience with Scala, but so far Kotlin feels better. With Scala it is possible to create really cryptic looking code and for some reason I like Kotlin syntax better. So, if you are a Java developer having experience with Javascript, I would recommend to try Kotlin for next generation language.

The fun part

Because Kotlin is a modern language, it has type inference, function literals and extension functions etc. which are completely missing from Java. Extension functions allows me to write something that I have always wanted to do. Consider following Java-code that traverses directory tree:

File root = new File("...");


for (File file : root.listFiles()) {
  if (file.isDirectory()) {
    traverse(file);
  } else if (file.getName().endsWith(".xml")) {
    handleXml(file);
  } else if (file.getName().endsWith(".png")) {
    handlePng(file):
  }
}

What bothers me with this code is that It has file.getName() twice in the code. If that method would be expensive, it would be a problem. That can of course be fixed for instance like this:

for (File file : root.listFiles()) {
  if (file.isDirectory()) {
    traverse(file);
  } else {
    String name = file.getName()
    if (name.endsWith(".xml")) {
      handleXml(file);
    } else if (name.endsWith(".png")) {
      handlePng(file):
    }
  }
}

That is better, but I still feel that more could be done. How about this example?

String email = person.getContactInformation().getEmail();
if (email != null && isValid(email)) {
    sender.send(email, title, msg);
}

That code contains a lot of things. First, there is a temporary email-variable to hold the value hidden deep in the object tree. Then there is an if-condition to check whether email can be sent at all. This is kind of normal Java-code in that sense that there is always a null-check, just to avoid possible NPE.

There is the method isValid(), but it does not really say anything about null-emails. It is possible that null-email is a valid option and the signature also does not say anything. It might be possible to replace it with isNullOrValid() but not everyone likes adding Or or And-words in methods. In any case null-checks are so common that they tend to pollute code a lot.

Also the temporary variable email is not nice. It is used only for a small amount of time, but it may be visible for all code in the rest of the method body. This can of course be fixed with making an own method to handle email sending like this:

private void sendEmail(String email, String title, String msg) {
 if (email != null && isValid(email)) {
    sender.send(email, title, msg);
 }
}

So, that is the Java-way of doing things.

But, what I have been longing for is a simple function that takes a variable or a return value of a method and applies a function on it. And in Kotlin I'm able to write just that, and it is:

public fun Any._<T>(func: (t: T) -> Unit) : Unit {
    func((this as T))
}

When that is used, code looks a bit different. Take for instance the directory traverse example in Kotlin:

val root = File("...")


root.listFiles()!!.forEach({ file ->
  if (file != null) {
    if (file.isDirectory().sure()) {
      traverse(file))
    } else {
      file.getName()?._<String>{ name ->
        if (name.endsWith(".xml").sure()) {
          handleXml(file)
        } else if (name(".png").sure()) {
         handlePng(file)
        }
      }
    }
  }
})

Also the email-example might look like this:

person.getContactInformation().getEmail()?._<String>{ email ->
    if (isValid(email)) {
        sender.send(email, title, msg);
     }
}

Or how about these examples:

FileInputStream(file)._<InputStream>{ stream ->
    // do something with the stream
    stream.close()
}


val person = findPerson()
person.getContactInformation()?._<ContactInformation>{
    it.email = other.email
    it.phoneNumber = other.phoneNumber
    ...
}

In all these examples the information (or variable) at hand is simply encapsulated inside a local function and forgotten when not needed anymore. Also null-checks are clearly visible where needed. It also make sure that if the return value or variable would be null the function is never called and no explicit if statements are needed.

I could not find a way to infer the type for the _-method and it may lengthen the function. It would certainly look nicer if the type parameter and the method name itself could be removed. Then it would really look concise. For instance like this:

person.getContactInformation().getEmail()? {
    if (isValid(it)) {
        sender.send(it, title, msg);
    }
}

Maybe that construction could be taken into Kotlin itself in some form :-D. Anyway, these are my first steps learning Kotlin and so far I have really liked what I have seen. Keep up the good work.

Context Framework goes to Cloud

A few months ago I wrote a blog post how Context-applications could be clustered. Also the last blog post was about state handling and there I also touched the subject of clustered environments. For short reminder, Context is a stateful web framework and it means that it cannot just be clustered same way as stateless frameworks and in the first post I proposed three different ways to cluster stateful applications.

1. Session affinity
2. Node hinting
3. Node proxying

All these ideas are usable, but I still wasn't happy with it. I wanted to solve the problem: how to share a page scope in a cluster using a database. It should be possible to activate and deactivate cluster nodes by demand, and not to worry whether node has some important information stored into it.

This is now reality in version 0.8.5 which brings native support for clustered environment, and in this blog I want to share what was required to do such effort. It basically meant that two big challenges had to be solved.

1. Page scope must be serializable

There exists a number of different serializing techniques and using them to serialize an object graph is quite simple. That was no brainer. However the challenge was that page components have dependencies to classes that are not serializable. For instances services, or any other "singleton scoped" objects, are such dependencies, and with Guice it is trivial to inject whatever dependencies to components. So this was a big issue.

What I needed was to find a way to detach external dependencies and then retach them back on during deserialization. I chose XStream for the serializer and after some pondering and tweaking its DependencyMapper I was able to do exactly that. I introduced an annotation called @Provided and it marks the dependency be injectable by Guice and can be attached/detached during serialization and deserialization. Also Guice-providers are automatically detached.

For serialization itself I chose binary format. Pure XML-serialization was too large and if XML was compressed, it took some unnecessary processing power. So, binary stream was a good trade off between size and cpu consumption.

2. Page scope access must be synchronized

Other big challenge was synchronization between cluster nodes. The basic thing is that only one server and one thread should be accessing page scope at the same. Concurrent access does not work well, because updates may become mixed and put the scope into inconsistent state.

In reality, the synchronization problem is rare, but it may happen if user is clicking functions in fast pace, thus multiple requests are trying to do something in the page. Of course it has to be remembered that synchronization is needed only within one page, not across different pages.

I chose MongoDB as first persistence implementation and this problem had to be solved in database level.

The basic idea is following. Each mongo-document has a lock-field, which is telling wether document is accessible or not. When page scope is tried to be accessed, the FindAndModify-command is used. Thread looks for document with false in the lock-field and tries to set it true.

If document cannot be accessed thread will sleep for a short period of time (100ms) and try again until access is acquired. In such scenario that there are too many try outs (about 10 seconds), page scope is accessed anyway instead of failing. I figured that this option is better than just some dummy failure.


Other than those challenges, rest was just hard work and refactoring, and so far I'm happy with the results.

Affects on performance


It is obvious that constant serialization/deserialization have impact on performance. So far it seems that the impact is about 10-30ms per request depending on database connection latency and the size of the page scope.

It remains to be seen how much that impact affects overall performance, but Context has on particular advantage over many stateless approaches. To fetch data from server, the amount of needed requests is much lower. Normally just one request is needed to get everything.

For more information check out the documentation for cloudability support.

I am also building a demo-application that I try to keep demonstrating newest functionalities. It is currently hosted at Cloudbees with "Free plan" using 2 node instances.

All web applications are stateful

I recently read some blog posts (1 and 2) about web application development and the evolution from thin clients to fat clients, from server-centric to client-centric dynamic applications.

Traditionally web clients have been dummy and known basically nothing. Now the demands are the opposite. Servers are stateless or dummy and clients contain all state and logic. Everything should be "web scale". Systems should be able to handle millions of requests per second. Well, of course not everyone is building Facebook or Twitter, but that is the trend.

In my mind all this winds up to one big challenge: where is the state of functionality handled? Is it on server, on the client, or on both? There exists a number of frameworks with different state abstractions from "share nothing" stateless frameworks (e.g. Play) to stateful frameworks (e.g. Context and Lift). They all approach this dilemma in different ways.

So, I decided to make some comments on the matter. Basically, I'm trying to remind that even if application is built with "share nothing" mindset, it does not mean that state does not exist. It is still everywhere and it requires a lot of thought.

I should note that this post contains a lot of questions without answers. I'd be happy to hear your thoughts.

Where is the state of data?

Web applications are not built for nothing. They are most likely modifying data in different ways. It is also likely that the data is shared amongst multiple users. This creates state; the shared state of data.

In my understanding, the basic idea with stateless client-centric approaches is that client basically fetches all the data that is needed for functions and it is manipulated locally. Then at specific points the local data is synchronized with the server and exposed to others. Now, my concerns are:

1. How much information must be fetched from the server? If database contains millions of records, does the client need all of them or just some subset? How does the client know what is the correct subset?
2. If the client has only a subset of information in use, how does it know how the "unknown" part of the data affects it?
3. How does the client know when something changes? It is obvious that client's own changes are easy to synchronize, but how about changes made by others?
4. How is the changeset fetched? How does the client know what changes to fetch instead of downloading everything just in case?

In more traditional approaches the client has a web page that contains the relevant data given from server and nothing more. Then, when some actions are made a form or similar is submitted. Server handles it and new page with brand new state is returned. Also if there are conflicts during form submit it is the responsibility of the server to do something with it. In any case the state is cleaned and a new page is shown.

But if server is only providing data, collections of objects, how does the client keep track on everything? And if something nasty would happen, how does the client know about it? And what do you do if that is the case? How do you clean the state in the client? Reload perhaps...

Where is the state of business logic?

I believe that one driving force to fat clients is that business logic could be done on clients and it would reduce the amount of needed processing power on server. I may understand this incorrectly, but if such scenario is assumed, doesn't it lead to logic duplication?

The point is that client cannot be trusted and it does not know everything. For instance, it is a basic understanding that data validation made on client must be revalidated on server. It is just too easy to bypass all client validations. So, it quickly leads in a situation that logical decisions should also be revalidated on server.

Also the shared application state among different clients is a challenge. Let's say that the application would be some kind of calendar based reservation system for hairdressers. It allows clients to choose a hairdresser and then create, remove or rearrange reservations online. So, if the client has all the power on manipulating reservations, how is it restricted and controlled?

Server should probably validate the manipulation so that no duplicate reservations can happen and that client cannot forge reservations in some odd manner. Maybe in some case the client cannot find times for the hairdresser she would like to have. So she simply reserves time to someone but forges the hairdresser id. With luck, she might just bypass something and the existing reservation is replaced with new one on the server.

So, basically I have a feeling that with fat clients, developers end up writing a lot of duplicate validation on server. And not only field validation, but also logic validation.

Signaling exceptional states

This topic does not concern only stateless applications, but is a comment about one general issue. If something goes awry, how do you tell it to the client?

This dilemma is universal because almost every request/response-case is built in a same way. Client creates a request and sends parameters with it. Server takes the request and calculates response and returns it. If something goes wrong, exceptions are thrown and logs are filled with stack traces.

So, how is exceptional state returned to client? In my understanding restful approaches normally use HTTP 4xx codes for it. But how do you tell what went wrong and what to do about it?

Signaling multiple state changes

Signaling multiple states changes is also a big issue and is in close relation with exceptional states. How must a request/response be formulated so that it can give different kind of answers?

The thing is that normally the client is expecting to have a certain type of response and nothing else. This is especially challenging in Javascript, because if the return value is JSON, client cannot automatically tell what entity it represents. It must be assumed.

This issue arises especially from the user interface. The more dynamic application is the more it will have multiple sections on the page that may update themselves independently. To support all the changes, multiple type of information is needed.

This issue may sound distant with traditional MVC-based approaches, where it is expected to have one answer to one request. But as soon as you start doing something with component based frameworks, the issue quickly becomes closer. The mindset changes and you start thinking: "Couldn't I just change also that thing?".

So, how is it done? Can one request return multiple responses, or does the client need to make multiple requests? How does the client know what requests to make and how to interpret the responses?

To session or not to session?

The extreme part of stateless approaches are saying that no sessions should ever be used. Session affinity is a bad thing and prevents scalability.

If server based sessions are not used, it automatically creates an obvious question: How does one handle user authentication? How does the server know if the client is allowed to access certain parts of the system?

One solution is just to use cookies that hold user id or similar. But can client tamper that information somehow? When that question arises, it is quickly obvious that the cookie must somehow be encrypted or signed so that only the server knows how to use it.

Now, if server does not keep any record of the cookie's state how do one expire the restricted access? How do you logout? The point is that if server does not keep any state, even with expiration time for the cookie, client can always recreate it and keep logged in forever.

Well, the answer is probably some kind of encrypted and time stamped cookie that is renewed at server whenever it is accessed. And during logout cookie is simply expired at server.

But still, how does one force expiration? The session can always be discarded by the server, but how do you discard the knowledge of the cookie's content in the client? If the client just keeps recreating the last known working cookie, how does the server know that is not valid anymore?

So, what might happen is that developers end up writing some custom database based solution that keeps track of accepted cookies or user's expected state; the state of the session.

A real-life case of the state problem

For the last part, I decided to share a real-life puzzle that I encountered recently regarding state.

I'm currently porting my clients codebase to Context and I encountered a situation that actually made me write this post. The system contains a search page for certain items. In a sense it is just basic stuff with search form and paged results etc.

Now the twist is that when the first results of the search are shown it is possible to create a report for the full set of the matching items. The report itself is nothing fancy really, just some statistics and numbers. But the key point is that generating the report takes time.

If there are a lot of matching items it may take over a minute to finish the report. It is CPU-intensive, database-intensive and IO-intensive. It takes time to crawl the database and crunch the numbers. It would also be nice that not every user is able to start generating their reports in parallel. It would just starve the system.

So all this screams for one thing: a background job. Search page should create a job-on-demand and wait for the results to emerge into existence and finally show them. And if there are multiple jobs they are processed serially. But all this creates a new state, the state of the job on the server. It is not the client doing the crunching, it is the server. So, how is it handled?

In Context that problem is relatively simple. All that is needed is to create a proper object to hold the state and progress of the job, give it to thread pool and associate the object to page state. After that it is trivial to poll the server periodically and check how the report is generating. When everything is finished results are shown in client. The job lives in the page state, and when the web page is closed, the job is also ready for garbage collection.

But how about stateless application? How are following questions solved?

1. Where does the job live? Where is it kept?
2. How is the job accessed? How does the client know what is the correct job?
3. How is the progress of the job tracked? Is it possible to tell user that for instance 40% of the job is done at certain moment of time?
4. How is it prevented that one user cannot see other users jobs?
5. How do we know when the results of the job have been consumed and can be discarded on server?

Also, if you are having clustered application more questions must be tackled:

1. Which server is doing the crunching?
2. How is the background job invoked?
3. How is the data accessed if every request goes to random server?

I have no answers to these questions. There may be a number of solutions, but I have a feeling that it requires some kind of external server and that the data must be saved temporarily to the database.

Well, that's about it. I hope that these thoughts are helpful on your journey on web application development whatever programming language or framework you are using.

Clustering Context-application in Cloudbees

Scalability and clustering is normally associated with stateless web applications. Because Context is stateful, I began to experiment, what is needed to serve Context-application from the cloud. I was introduced to Cloudbees, which offers 2 nodes in their free subscription plan.

First thing is important to understand that, in Context, state does not rely on cookies thus it does not rely on http-session. Instead it relies on UUID that is created for each page load and all page update use that token to identify which page should receive the update request.

This means that, from the clustering point of view, all page loads can always go to any random node, but all subsequent ajax-calls on each page must go to the original node. Resource-requests (images, js-files, css-file etc.) can always go to any random node

So, there are at least three ways to handle clustering that suits Context-applications.

1. Session affinity

This is the most basic way to handle the situation. With session affinity all page loads are directed to same node for the same user. It will work, but is not the most "pure" option. The good thing is that session affinity is a known technique and it has support, although Cloudbees does not offer it yet. So, if session affinity is offered everything should be set.

2. Node hinting

This is the way I'd like clustering to happen. In this version each node exposes some kind of token that is sent to web client and if the client sends the same token back during request, then the load balancer will automatically send the request to the originating node.

This would allow each page load request to go to any random node, but all ajax-request would go to the originating node. Unfortunately, in my understanding, this option is not supported.

3. Node proxying

Because the options above were not supported in Cloudbees, I thought something different. Simply, could nodes proxy each other?

Basically this scheme is the same as option 2, but with a twist. When page load is requested, the local IP-address and TCP-port of the node is sent to web client (with hash). And that is sent back to the cloud during ajax-request.

Then the receiving node will check if the ip-address and port belongs to it. If so, call is served. If not, the node will proxy the request to correct node using the local ip-address and port. This was a technique that actually works in Cloudbees.

There is a live demo at Cloubees that demonstrates the behaviour. I had to make a custom http-proxy-filter and if you are interested the example is found here. It is not perfect, but at least shows the idea.

Now, these options has some challenges though. One partical challenge is that depending on traffic new nodes can be brought alive or shutdown. It is always ok to start new nodes, but for shutting them down may be problematic. If the node still contains some users, their pages will suddenly stop from working. So, it basically means that the number of nodes should stay the same.

New features in 0.8.4

Also, new version has been released. Here are the prominent changes.

Extended live class reloading

Version 0.8.3 brought live class reloading to pages and components with limitations. Those limitiations were that creation of new pages required server restart, so that their mappings would be registered. Version 0.8.4 removes that restriction and in development mode new pages (or removals) are discovered at runtime.

This change means that for most of the time no server restarts are needed. Complete documentation is here.

Path- and Request-param-mapping

This version also brings support for mapping path- and request-parameters as view component properties or as methods. This happens with two annotations @PathParam and @RequestParam.

Example:

http://www.example.com/myview/10?search=contextfw

@PageScoped 
@View(url="/myview/<id>")
public class MyView extends Component implements ViewComponent {

  @PathParam
  private Long id;

  @RequestParam
  private String search;

  @Override
  public void initialize(ViewContext context) {
    System.out.println(id + ":" + search); // => prints 10:contextfw
  }
}

Complete documentation is here.

JSONP-embedded mode with RequestInvocationFilter

RequestInvocationFilter is more esoteric and advanced feature and is not needed in everyday use. But in essence it is way to create filtering to page initialization and updates in similar manner as regular servlet filter. The difference is that this filter does not touch resources as images or css-files.

The filtering was implemented to enhance embedded mode usage. In normal embedded mode same origin policy is applied, but modifying contextfw.js-file and applying invocation filter, it is possible to embed pages in JSONP-mode thus pages can be embedded everywhere.

At this moment JSONP-mode is experimental, but if you are interested in it, I'm happy to share my experiments so far.

Documentation about embedded mode is here.

Context 0.8.3 gets live class reloading and other things

This is really exiting. Context 0.8.3 has just been released and it just keeps getting better. Live class reloading has been a long dream and one weekend I decided that I will now try to make it happen.

I have used JRebel for code-hot-swapping and it has worked great. But because it is a separate commercial product, it cannot be the only option.

So after finding information about class loading etc, about eight hours later live class loading became alive. :-D And in quite elegant way actually.

Now, in Context every page load gets own set of objects to handle the page state. So, what I actually did was to attach a throwaway class loader to that process. When page is reloaded and class changes are detected a new class loader is created for new page loads.

The especially nice thing about this approach is that even classes from service-layer can be reloaded.

Basically the only concern is that live class reloading creates a two set of classes; those that are reloadable and those that are not. If class can be handled purely by annotations and Guice then it is probably reloadable.

This separation means that classes that are non-reloadable must not depend on reloadable classes. Otherwise there will be linkage errors. But with reasonable organizing that should not be a problem.

Remote method interception and data validation

In Context page update requests are translated into component method calls which creates a good question. Can that call be intercepted in AOP-like manner? This is important, because method execution may require certain privileges or parameter validation.

The normal approach would be to create proxies that handle the AOP-stuff. This is however, problematic because it prevents using new-operator and I have never liked that restriction.

Now, because the remote call is translated from certain url to method call, it is actually called via reflection. So, the solution was simple. I simply added a new method to LifeCycleListener-interface, that is called every time when method should be invoked. All data validation and other checks can be done in that method.

Secure way to recover lost password or user name

Most web applications that needs authentication has a common requirement which is the ability to recover lost password or user name. This has been discussed in many blog-posts before, for instance here.

In this post I'm presenting a secure way of revovering password using Context Framework and its key feature page scope. The goal is to make recovery resistant against data forging or data interception. That is, the system should resists false password recovery attempts or stealing victims emails.

In short, page scope is an exclusive data area on server that is unique to each opened page on user's web browser. That is even if same page is opened in multiple browser tabs the page scope is unique for each of them. Page scope is independent from session and does not use cookies. The security of the scope relies on random key (UUID) that is generated for each page.

In the scenario I have following assumptions:

1. User has a user name and a password
   
2. User has an email that she trusts and is registered to the system
   
3. User has forgotten her credentials and needs reminder and if necessary a way to change password
   

In login page there exists a page component called Authenticator. It provides following features:

1. A login with user name and password
2. Credential revocation with email

If user finds herself in situation where she has forgotten her username, password or both she needs to user her email to recover them. The Authenticator contains two additional input fields (may be hidden at first). First one is for user's email address and second is for a security key for later use.

User enters her email and requests the Authenticator to send recovery email. The Authenticator receives the request and stores the email to page scope. To be more accurate the component itself is stored in the page scope, so storing the email is a simple as setting a class property.

Then the email is forwarded to Authentication service. The service then creates a random key, using for instance UUID. Then it checks whether the email exists in the system. If email is found the service sends a message to the email, containing the random key and informs that the key should be entered to another input in the page where the request was made.

If email is not found, then email simply contains information about that.

After sending the message, service returns the created key to the Authenticator. The key should be returned even if no proper email is found. In this way user cannot start guessing what emails might exist in the system.

Service could also send an exception or whatever error code. The important thing is that Authenticator must behave exactly the same as email would be valid.

Then what happens is that the Authenticator stores the key in to the page scope and begins to wait for the user to enter the key.

When user has received the email, she copies the key and enters it to the security key field. Authenticator receives it and checks that the entered key and the stored key match. If they don't an error message is shown. If they do, component knows that the email is valid.

The Authenticator then asks from Authentication service for the credentials that match the given email, and gets user name as return value. Then it displays the user name as plain text. If user is now able to remember her password, she simply logs in and everything is ready.

If she does not remember a password, Autheticator then shows an input field to create new password. The password can be checked for complexity etc. but in the end user sends a new password to server. The Authenticator receives it and asks the Authentication service to change password for the user name it received during recovery process.

After that user can be logged in automatically or require to login manually. At this point the process is ready.

Why is this scenario safe?

Email and security key are stored on server and they are not requested from user afterwards, so neither of them can be fabricated during later calls.

Also, intercepting request email is useless, because the random key is usable only on the page where the original request was sent.

Page scope lives only as long as the page is alive. As soon as page is unloaded or expires for some other reason, the security key is no longer usable at all.

Other Benefits

This scenario does not require any secret keys or hashes to ensure that requests are not forged. The contents of the sent email stays simple. Revocation process also do not require external pages to process it. Everything is handled on the same component. Process also does not need cookies because revocation is done outside of session.

This example demonstrates what benefits a stateful web framework has. It provides means to hide information form clients and store them on server so that information cannot be tampered with.

If you think that this scenario is unsafe, I would be happy to hear some comments.

In this Gist is a little snippet as Java-code to clarify what the component and service might look like. All templates and possible javascript-parts are exluded in the example.

Also check out the new features of Context that the 0.8.1 has to offer.

Update: 2011-06-29

I was given a comment on DZone that I should emphasize more that this has nothing to do with protecting entire session and that is true. This blog post concentrates only password recovery process where possible attacker might want to forge or circumvent the process some other way.

For example, an attacker might initiate password recovery with her own email, but forge later requests in such way that process continues with someone else's email or she could simply create a fake process altogether.

For protecting entire session and HTTP connection I recommend to to familiarize yourself with OWASP Top 10 risks and in this case session hijacking.