In

This needs to be configurable if the keycloak host is different then the shogun host.

I'm trying to create ~20000 new entities and also set permissions for every one. Unfortunately, GroupInstancePermissionService::setPermission takes about 3 seconds per permission.

See

Ideas:

• is the check for existing permissions necessary (especially for new entities)? could this be optional maybe?
• we could provide a method setPermission(List<BaseEntity> persistedEntities, Group group, PermissionCollectionType pct) where repository.saveAll() can be used to create many permissions for a single group

Other suggestions are welcome…

We should add interfaces for partial updates of entities.

HTTP PATCH should be appropriate for this case.

Currently if we have large objects or objects with read-only fields we need to send huge objects and do some crazy workarounds.
When changing just one attribute of an entity, there should be an interface to post only this one changed attribute.

🚨 The automated release from the main branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you can benefit from your bug fixes and new features again.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can fix this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the main branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here are some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

failed to deploy to maven

Unfortunately this error doesn't have any additional information. Feel free to kindly ask the author of the @terrestris/maven-semantic-release plugin to add more helpful information.

Good luck with your project ✨

Your semantic-release bot 📦🚀

The BaseService.update method serializes the given entity, deserializes it again and saves it. This causes the resulting object to not be a proper hibernate proxy. (edit: to be more precise: any related objects are no hibernate proxies anymore, but merely the objects that got deserialized. It can be that the object only contains an Id if the field was using the BaseEntityIdSerializer). Also all other managed instances of the object are broken as well.

Firstly the question arises why this code with the serialization and deserialization exists:

    @PreAuthorize("hasRole('ROLE_ADMIN') or hasPermission(#entity, 'UPDATE')")
    @Transactional(isolation = Isolation.SERIALIZABLE)
    public S update(Long id, S entity) throws IOException {
        Optional<S> persistedEntityOpt = repository.findById(id);

        ObjectNode jsonObject = objectMapper.valueToTree(entity);

        // Ensure the created timestamp will not be overridden.
        S persistedEntity = persistedEntityOpt.orElseThrow();
        OffsetDateTime createdTimestamp = persistedEntity.getCreated();
        String serialized = createdTimestamp != null ? createdTimestamp.toInstant().toString() : null;
        jsonObject.put("created", serialized);

        S updatedEntity = objectMapper.readerForUpdating(persistedEntity).readValue(jsonObject);

        return repository.save(updatedEntity);
    }

I suppose this in place to leave the entity intact. Is this really neccessary?

The simplest way to achieve the same would be:

  entity.setCreated(persistedEntity.getCreated());

Another way to solve this would be to use the lombok @SuperBuilder annotation and create a copy. See https://www.projectlombok.org/features/experimental/SuperBuilder

For our project we used the following workaround:

            var updatedEntity = super.update(entityId, entity);

            entityManager.flush(); // flush database changes
            entityManager.detach(updatedEntity); // this way the broken object is no longer a managed hibernate object
            // without the detach the findById would just return the broken managed object
            updatedEntity = repository.findById(entityId).orElseThrow(); // get a new managed hibernate proxy object

This might not be feasible for the BaseService as I assume that flush does have performance issues if called often.

A client util should be provided in order to generate interceptor rules easily via HTTP.

Follow up to #22

The default user shogun is not assigned the role ADMIN by default. Therefore some requests can not be executed (e.g. the actuator). Currently, this must be done manually via Keycloak.

The script for setting up the default users must be modified accordingly.
It is suggested to use the JSON Export/Import function of Keycloak to set up all necessary data.

If we introduce new flyway migrations (that should for example be necessary for #247 and #258) this will work for a standalone shogun-boot setup, but project implementations might fail during applying the migrations as they might have added migrations already. As an example: Adding V1.0.0__my_new_shogun_migration.sql would breakup the migration order if the custom project already contains V2.0.0__my_existing_project_migration.sql (V1.0.0 < V2.0.0).

Any ideas on how to get around this problem?

The util classes KeycloakUtil and SecurityContextUtil contain several more or less identical methods.
This needs to be cleaned up.

e.g:

• KeycloakUtil.getKeycloakUserIdFromAuthentication vs. SecurityContextUtil.getKeycloakUserIdFromAuthentication
• KeycloakUtil.getUserGroups vs SecurityContextUtil.getKeycloakGroupsForUser
• …

the jib build is triggered on mvn package. In the pom.xml is this config for the jib plugin:

          <executions>
            <execution>
              <id>dockerBuild</id>
              <goals>
                <goal>dockerBuild</goal>
              </goals>
              <phase>package</phase>
            </execution>
            <execution>
              <id>build</id>
              <goals>
                <goal>build</goal>
              </goals>
              <phase>deploy</phase>
            </execution>
          </executions>

It might be enough to change the phase of dockerBuild to deploy. What do you think?

Add

.ignoringAntMatchers("/graphql")

to
https://github.com/terrestris/shogun/blob/master/shogun-boot/src/main/java/de/terrestris/shogunboot/config/WebSecurityConfig.java#L60

With #164 the version of spring-boot dependency was updated from 2.3.5.RELEASE to 2.4.0.

With this change the config file processing in Spring Boot was changed (s. https://spring.io/blog/2020/08/14/config-file-processing-in-spring-boot-2-4#multi-document-properties-files) so the existing structure of application.yml files does't match anymore and customized project settings (e.g. profiles) doesn't get overriden in children projects.