Feature/1182 collaborator api communication with keycloak

[Bushuo]

Basics

• The PR is rebased with current master
• I added a line to changelog.md
• Details of what I changed are in the commit messages
• References to issues, e.g. close #X, are in the commit messages and changelog
• The buildserver is happy

Checklist

• I fully described what my PR does in the documentation
• I fixed all affected documentation
• I fixed the introduction tour
• I wrote migrations in a way that they are compatible with already present data
• I fixed all affected decisions
• I added automated tests or a manual test protocol
• I added code comments, logging, and assertions as appropriate
• I translated all strings visible to the user
• I mentioned every code or binary not directly written or done by me in reuse syntax
• I created left-over issues for things that are still to be done
• Code is conforming to our Architecture
• Code is conforming to our Guidelines
• Code is consistent to our Design Decisions
• Exceptions to any guidelines are documented

First Time Checklist

• I have installed and I am using pre-commit hooks
• I am using Tailwind CSS Linting

Review

• I've tested the code
• I've read through the whole code
• I've read through the whole documentation
• I've checked conformity to guidelines
• I've checked conformity to requirements
• I've checked that the requirements are tested

[Bushuo]

jenkins build please

[Bushuo]

@markus2330

Die Variablen hinzuzufügen ist aber glaub ich noch zu früh, da ist imho noch Diskussionsbedarf. Lieber wäre mir eigentlich es gäbe so etwas wie KEYCLOAK_PASSWORD nicht, und es wird der Login vom Frontend verwendet.

Das ist leider nach meinem Erkenntnisstand nicht möglich. Die Admin REST API erfordert einen Login über den Admin Account. Das hab ich nur mit den variablen die ich definiert habe geschafft.

Damit könnte man dann auch steuern, dass nur Members andere Members sehen können (und nicht die Gäste).

Das verstehe ich nicht. Die role (member) kommt aus dem Token. Die anderen user kommen über ein request an die admin rest api. Man kann wsl auch die role mit der Admin api abfragen und dann filtern was als Suchergebnis zurück kommt.

[markus2330]

Fantastic work! ❤️

Some suggestions how I would prefer the keycloak config to be but I didn't check if keycloak actually provides this possibility. So maybe the current way already is the best. 🚀

"owner" renames etc. could also be in follow up (and is probably even better).

Please always try to say why something is draft or what is open, it helps in a review.

Das ist leider nach meinem Erkenntnisstand nicht möglich. Die Admin REST API erfordert einen Login über den Admin Account. Das hab ich nur mit den variablen die ich definiert habe geschafft.

Thx for clarification.

Damit könnte man dann auch steuern, dass nur Members andere Members sehen können (und nicht die Gäste).
Das verstehe ich nicht. Die role (member) kommt aus dem Token. Die anderen user kommen über ein request an die admin rest api. Man kann wsl auch die role mit der Admin api abfragen und dann filtern was als Suchergebnis zurück kommt.

Yes, looks like you already do what I meant. I meant that the person who is requesting to search for others should be restricted if (s)he is not a member.

[Bushuo]

@markus2330 I think this PR is ready now

[chr-schr]

I just reviewed this PR and it overall it looks solid to me 👍
One problem is it breaks the devcontainer (missing the new AUTH_HOST env var)
Also had some minor suggestions / thoughts.

[chr-schr]

Should we create a ticket for this?

[Bushuo]

Yes, I do not know if it is problematic to potentially send an unbounded amount of update queries to the DBMS.
We could open a discussion in the diesel_async repo and ask for guidance.

[Bushuo]

I just reviewed this PR and it overall it looks solid to me 👍

Thanks for the review. Nice catches :)

[markus2330]

@lukashartl and I will try tomorrow to fix the env vars and do the Keycloak setup.

[Bushuo]

@lukashartl and I will try tomorrow to fix the env vars and do the Keycloak setup.

Ping me if you need assistance.

[Bushuo]

@markus2330
what is the status of your testing? I would like to get this merged or keep working on it if it still needs work.

[markus2330]

what is the status of your testing? I would like to get this merged or keep working on it if it still needs work.

I'll start testing when also frontend is ready. We can merge this when @lukashartl has fixed our keycloak+infrastructure to accept the env vars. We probably even need 3 steps:

1. first fix pr.permaplant.net
2. then dev.permaplant.net (and retrigger master builds until it works)
3. and then fix www.permaplant.net (and release again)

[Bushuo]

I'll start testing when also frontend is ready.

Ok. I have the frontend ready on a separate branch that is based on this branch.
I decided to rework the map creation and edit page. This also fixes #706, #1166 and #1163.
Should I open another PR for it, even though this is not merged?

We can merge this when @lukashartl has fixed our keycloak+infrastructure to accept the env vars.

Alright, I also have a fix for #755, the first two of #1093 and #480.
They all depend on this to be merged first.

[markus2330]

jenkins build please

[markus2330]

Keycloak was now reconfigured for this PR, let us see if the build succeeds.

[markus2330]

Failed with:

/home/jenkins/workspace/PermaplanT_PR-1184@2/frontend/node_modules/vite/node_modules/rollup/dist/native.js:64

		throw new Error(

		      ^


Error: Cannot find module @rollup/rollup-linux-x64-gnu. npm has a bug related to optional dependencies

[Bushuo]

@markus2330
thats good news.
I will get it to build in the evening.