Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

POST duplicate entry not causing PK collision in Spring Data REST [DATAREST-1007] #1370

spring-projects-issues opened this issue Feb 14, 2017 · 3 comments
in: repository status: feedback-provided type: bug


Copy link

spring-projects-issues commented Feb 14, 2017

Jianzhao Li opened DATAREST-1007 and commented

As per Spring Data REST Documentation, POST method creates a new entity from the given request body. However, I found it could also update the existing entity. In some cases, this can be problematic. Here is an example:

package com.example;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

public class DemoApplication {

    public static void main(String[] args) {, args);

package com.example;


public interface UserRepository extends PagingAndSortingRepository<User, String> {}

package com.example;

import javax.persistence.Entity;
import javax.persistence.Id;

public class User {
    private String username;
    private String password;
    public String getUsername() {
        return username;
    public void setUsername(String username) {
        this.username = username;
    public String getPassword() {
        return password;
    public void setPassword(String password) {
        this.password = password;

pom.xml (within project tag)



<description>Demo project for Spring Boot</description>

    <relativePath/> <!-- lookup parent from repository -->




{cdemo} empty

URL: http://localhost:8080/users

Method: POST

JSON content:

I assumed the above POST request was getting HTTP 201 at the first time, and only for one time. However, I was able to send the above POST request many times, and got HTTP 201 all the time. In addition, I was also able to change the password in the database using POST request.

I believe that this is a security problem. For example, I might allow anonymous user registration through a POST request. But, with above situation, the existing user could be overwritten.

Question: How can I prevent a new entity being created from a POST request if an old entity has already existed with the same id? Or, did I miss interpret the Spring Data REST Documentation?
Supplementary explanation:

The cause of this issue is the design behind Spring Data REST. Because Spring Data REST is built upon Spring Data JPA, which was not used to directly expose to the "outside". So it "trusts" data that comes in. The method isNew in shows how data is determined as new or not new.

public boolean isNew(T entity) {

    ID id = getId(entity);
    Class<ID> idType = getIdType();

    if (!idType.isPrimitive()) {
        return id == null;

    if (id instanceof Number) {
        return ((Number) id).longValue() == 0L;

    throw new IllegalArgumentException(String.format("Unsupported primitive id type %s!", idType));

The result of isNew method will eventually effects save method in

public <S extends T> S save(S entity) {

    if (entityInformation.isNew(entity)) {
        return entity;
    } else {
        return em.merge(entity);

In the situation mentioned in this question, the username field, which is also the id of the user entity, would always contain data in order to create new users. Therefore, when it goes to isNew, id == null will always return false. Then save method will always perform a merge operation

Affects: 2.6 GA (Ingalls)

Reference URL:

Copy link

spring-projects-issues commented Feb 14, 2017

Oliver Drotbohm commented

I think we can cut this short: this is not related to Spring Data REST at all but caused by your (partially correct) identifier setup. As documented, Spring Data inspects the identifier property and only treats entities with a null, non-primitive value as new. As you hide this behind a manually handled property, the second call issues a merge(…) which eventually results in an update.

As documented, you can tweak this by implementing Persistable or rather switching to a dedicated auto-applied, synthetical identifier

Copy link

spring-projects-issues commented Feb 14, 2017

Jianzhao Li commented

I'm sorry. I didn't realize I can use @Version along with Persistable to solve this issue. Thank you very much!

@spring-projects-issues spring-projects-issues added status: waiting-for-feedback type: bug in: repository labels Dec 31, 2020
Copy link

spring-projects-issues commented Jan 7, 2021

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

@spring-projects-issues spring-projects-issues added the status: feedback-reminder label Jan 7, 2021
@gregturn gregturn added status: feedback-provided and removed status: feedback-reminder status: waiting-for-feedback labels Jan 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
in: repository status: feedback-provided type: bug
None yet

No branches or pull requests

3 participants