[QUESTION] Do you have an online course / tutorial for this repo

[zjjt]

Hi,

I was browsing the kgraphql.io documentation and i was redirected to your repository. I am in the process of building a saas app using ktor and graphql. Browsing the web for tips and help i came across this old tutorial https://michaelstromer.nyc/books/kotlin-multiplatform-mobile/ktor-and-kgraphql which i followed and made it somehow work with ktor 2 since kgraphql doesnt for now.

I was looking for a better way to handle authentication (with access and refresh tokens) and stumbled upon your repo. If you have a course or tutorial about it please forward it to me so i can improve my current architecture which is mostly organized as shown in the link above. If no videos are available then ill try my best to understand and update where it makes sense.

Thank you for the great repo

[zjjt]

Another quick question please.
Any tips on how one can go about extending it to support refresh tokens?

[ESchouten]

@zjjt in order to support refresh tokens, after login a refresh token cookie should be set (e.g. an UUID). This token should be stored in the User database entity as well.
Another endpoint should be created that reads the token and, if valid, returns the login JWT. This JWT should be short-lived (e.g. 15 mins) and the client should store this token in a variable.
If the client detects that the token is no longer valid (you can extract data from a JWT), it should automatically request a new one.
If the server refuses because the refresh token is no longer valid due to being old or due to being removed by an admin, the client should be redirected to the login page.

[ESchouten]

@zjjt I guess the best way to get familiar with the architecture is to play around with it. My philosophy is to keep the domain and usecase modules free of any libraries, except for libraries like kotlinx.datetime.
This way you can't clutter your business logic with, for example, library configurations and the interface with these libraries are clean and minimal. When you would switch libraries these interfaces would remain untouched.
See for example the Logger interface and the Authentication interfaces. The application does not know what logging library it uses, it only knows to call e.g. the function info or error on the Logger interface. This is called Dependency Inversion

[zjjt]

@ESchouten Thanks a lot for taking the time to reply. I am currently dissecting the project and i have learned a great deal about clean architecture from it (still learning though) and i am still trying to wrap my head around the reflection part for the auto generation of the graphql schemas.

Thanks for your detailed answer. I'll make sure to learn well.

I am trying to implement kmongo in the adapters/repositories and so far i have trouble with the User data class entity and tests since in one of them the database should be responsible for generating the ID. So far i have tried transforming the User data class into an open class and i have extended it in the adapter to create a data class UserMongo which overrides the id property to support @bson annotation and ObjectId ...It did work but i felt like this was too much of a hassle so i changed the original Entity interface 's id to _id : String. Despite all of this i am still forced to set the ID in code before creating a user in the collection and obviously the test fails since the ID in the database is the same as the one in the User instance...thanks again i am just thrilled to have read your answer. Ill find a way to keep everything clean and not modify my domain.

Thanks.

[ESchouten]

@zjjt Very relevant question! I have been thinking about that as well the last week's/month.
Personally, I am looking to create a small library that's able to add annotations to existing classes, this way the database annotations could be added separately from the domain layer.

For now I think a concession has to be made.
You could add the kmongo-id dependency to your Domain layer and configure the entities that way while keeping most of the database library and logic out of that layer.

I don't know if it would help, but alternatively you could lift the repository interfaces out of the domain layer into the usecase layer, so you could accept e.g. the CreateUserModel.

I think I would prefer the kmongo-id solution.

Oh, and for the automatic generation of the Graphql endpoints, please don't get confused by the complexity, that's specially created so we can forget about that part!

[zjjt]

@ESchouten glad to read you again. The library would indeed be a great addition to an already well structured project. I thought about it hard While away from my computer and as you said for now ill have to rely on having a dependency on kmongo-id in my domain layer. Thank you very much for the answers.From them, i am able to grasp bits of precious knowledge . Ill try looking for ways to add descriptions to the types queries and mutations and the a0 a1

[ESchouten]

@zjjt We're looking to have dynamic variable names as well, instead of the a0, a1 + the description. One developer replaced KGraphql with Graphql-Kotlin, and is able to support these named arguments. See the graphql-kotlin branch. You can read a discussion about it in #12 and #23

[zjjt]

@ESchouten ill take a look into those...being able to swap dependencies at Will without having to refactor everywhere is God sent...thanks ill check how he went about it

[zjjt]

@ESchouten I hope you have a very good day.

I would like to understand the two ways of authenticating proposed in the infrastructure module.
Which should one use. As far as i could understand , we have a REST endpoint for login which sets a cookie containing the JWT on the client and also we can call the loginUser query within graphql which gives us directly the JWT.

1. When to use each ?
2. should one prefer one to the other at all ?

In my case i'll have different clients (web, mobile, tv, watch) consuming the graphql content

PS:
I hope you dont mind me asking more question on the current thread as for it to serve anyone who might have fun while learning from the code here. If you do, may i open a discussion thread instead ?

Thanks 🙏

[ESchouten]

@zjjt I love having tech conversations! Please don't hesitate starting a discussion, would perhaps be helpful for other devs as well, or someone could enrich us with their insights!

I've created the REST endpoint mainly because KGraphql manages the request in the Graphql endpoint itself, so we can't add the JWT cookie ourselves.
Since Ktor 2.0 we have the Kgraphql plugin code in our project itself, so perhaps we could add some kind of configurable request lifecycle hooks, so we could filter out the Login usecase and append the cookie to the request. This would make the REST endpoint obsolete.

For web, you should probably prefer cookies, especially if you want to store the token so you stay logged in in a new browser session/web page reload. Localstorage is not safe for this usecase. If you don't want to save the token, storing it in a JS variable is fine as well.
For the other platforms I don't think it matters as much. I know the Android HttpClient supports cookies, but perhaps just setting the Authorization header is easier, both is supported in this backend.

[zjjt]

@ESchouten Superb.

I will start a discussion then and if other devs wish to onboard it will be easy.

I understand better now...Indeed for the web i can use the REST endpoint with the cookie to be on the safe side and since this backend support both..i can use even a mix of them both (REST,GRAPHQL) or use one over the other depending on the frontend platform.

I thought of something like this for example on web:

1- hit the /login endpoint and get the cookie back either storing it in a JS variable or within http
2- using a graphql client , attack all other mutations and queries which needs auth
-->if the cookie is httpOnly ,i cant read it to get the JWT and normally it should be sent with every http requests. In such a case will the cookie be effectively sent and the graphql queries work as though the Authorization header is set ?

I went ahead and generated the logic for a refresh token in the form of a JWT. I added an expiry time on the initial access token of 15 min (tests) and for the refresh token 7 days. For the web, is it a good idea to also store the refresh token in a cookie as shown on the following shot ?

Dont mind the mistakes in the code... :)

Thanks for the insights. I really like the way you explain stuff and it makes sense.

[ESchouten]

@zjjt I'd say, the Refresh token is fine. This one you indeed want to store in a cookie.

The access token is most safely stored in a JS variable. This way malicious packages can't access it in e.g. localstorage, and CSRF attacks can't happen because the token is not stored in a cookie. So put the access token in the response body.

Added bonus is that this way, you can decode the token with a NPM package like jwt-decode, and read from it when the token expires. So you don't have to 'try' to do a request to an authenticated route in order to find out if your token is valid.

P.S. Soon, besides the Graphql API, all endpoints will be approachable from REST as well, including OpenAPI documentation from which the client can generate code like with Graphql. See #18

[zjjt]

@ESchouten excellent news . Great to know. The work you did on the graphql schema generation is outstanding. I find myself going back to it quite often...

Well noted ill keep an eye out for when the rest endpoints generation Will be effective.

Thanks a lot for the time.