Disabling ALPS does not remove the profile link [DATAREST-1119]

[spring-projects-issues]

Jeroen Reijn opened DATAREST-1119 and commented

In my project, we tried disabling ALPS, but this seems to be only partly possible.

For disabling ALPS we used a RepositoryRestConfigurerAdapter like:

@Configuration
public class ApiRestConfiguration extends RepositoryRestConfigurerAdapter {

    @Override
    public void configureRepositoryRestConfiguration(RepositoryRestConfiguration config) {
        config.getMetadataConfiguration().setAlpsEnabled(false);
    }
}

After a restart/redeploy we still see the profile link in the api root response:

{
  "_links": {
    "filtertools": {
      "href": "http://localhost:8081/api/v1/filtertools{?page,size,sort}",
      "templated": true
    },
    "profile": {
      "href": "http://localhost:8081/api/v1/profile"
    }
  }
}

If you actually go to the profile URL it also still works and you will see link relations for the exposed repositories, but when you navigate to one of the exposed repository profile relations a 404 response is returned. I'm not sure if this is wanted behavior, but I would have expected the link relation to disappear from the root response as well, unless other profiles can be configured, but I'm not aware of that

---

Affects: 2.6.6 (Ingalls SR6)

Referenced from: pull request #280

[spring-projects-issues]

Jeroen Reijn commented

I'll be working on adding tests, fixing my formatting, etc

[nirmalanims]

I want to disable ALPS but I am not able to find RepositoryRestConfigurerAdapter in org.springframework.data.rest.webmvc.config

I am using spring-boot-starter-data-rest 2.6.1
And included spring-data-rest-webmvc 3.6.0

Please let me know

[falk-stefan]

This issue looks familiar (see stackoverflow question).

I've tried:

@Override
public void configureRepositoryRestConfiguration(
        RepositoryRestConfiguration config, CorsRegistry cors
) {
    config.disableDefaultExposure();
    config.getMetadataConfiguration().setAlpsEnabled(false);
}

but the endpoint is still exposed and interfering with my web-application routes..

[kumarsen26]

any update on this?

[nico-leuchter]

Does anyone have a solution to this problem? 🤔 I'm skeptical that it's intended to always have an OPTIONAL (source (https://datatracker.ietf.org/doc/html/draft-kelly-json-hal#name-profile)) link object in the responses. Even if you disable ALPS, I fail to see the purpose of the configuration in that case. Any insights or solutions would be appreciated.

Before disabling ALPS:
Response

{
    "_embedded": {
       // EXCLUDED
    },
    "_links": {
        "self": {
            "href": "http://localhost:8080/data/item?page=0&size=20"
        },
        "profile": {
            "href": "http://localhost:8080/data/profile/item"
        }
    },
    "page": {
        "size": 20,
        "totalElements": 1,
        "totalPages": 1,
        "number": 0
    }
}

After:

{
    "_embedded": {
       // EXCLUDED
    },
    "_links": {
        "self": {
            "href": "http://localhost:8080/data/item?page=0&size=20"
        },
        "profile": {
            "href": "http://localhost:8080/data/profile/item"
        }
    },
    "page": {
        "size": 20,
        "totalElements": 1,
        "totalPages": 1,
        "number": 0
    }
}

As you can see the responses are identical. The only difference is visible if I visit: http://localhost:8080/data/profile/item. Beforehand I received a payload and after setting .setAlpsEnabled(false) I received a 404 Status Code.

[migueltercero]

Same problem. setAlpsEnabled(false) don´t disable ALPS. Expose this information is a security issue.