Details
-
Task
-
Status: Resolved
-
Blocker
-
Resolution: Fixed
-
1.0.8
-
None
-
6
-
SDK26: Ubuntu - Sample App/Doc, SDK28: Docs/Test/Release
Description
The Travel Sample Application introduces customers to using Couchbase through the SDKs, by demonstrating an app which authenticates against a cluster, and performs queries and searches.
The other SDKs have updated Travel Sample Apps for SDK3 / Server 6.5, and in addition a version that works with the Collections Developer Preview.
such as [-https://github.com/couchbaselabs/try-cb-java/tree/6.5.0-branch-]
.
The 7.0 updates to work with Collections can be seen in:
- https://github.com/couchbaselabs/try-cb-java
- https://github.com/couchbaselabs/try-cb-nodejs
- https://github.com/couchbaselabs/try-cb-python
& the front end is at https://github.com/couchbaselabs/try-cb-frontend-v2
.
A Scala version (two versions - with & without Collections) is needed, showing best practices in Scala programming.
We may as well start in SDK 1.2 with a version for the Collections-enabled data sample bucket in 7.0β.
Attachments
Issue Links
Activity
Couldn't get this to work with `docker-compose up` so I've reworked slightly, could you check https://github.com/couchbaselabs/try-cb-scala/pull/3 and modify if necessary to allow other uses (e.g. running locally etc.) ?
The actual CSRF issue seems to be fixed, yay! (I tested booking a flight, and checking the list of booked flights).
(I do now wonder if we ought to add CSRF in another microservice layer, or have the backends pass the token to frontend somehow? Not sure what best practice is, will open a ticket for docs team to think about later.)
Thanks, PR taken. No further changes needed I think. It works when then README is followed, e.g. docker-compose is used - I was just in the habit of running it without that during development. And the README already details how to change application.conf if running outside of the docker config, e.g. changing the host from db to localhost.
(I do now wonder if we ought to add CSRF in another microservice layer, or have the backends pass the token to frontend somehow? Not sure what best practice is, will open a ticket for docs team to think about later.)
Yes, probably. I also left this alone as I'm not confident on what the best practice is here. A solution (not sure if best) is for the server to send it in the login so it can be saved in the cookie, and then the frontend writes in into the POST form? Could just the JWT token for that then I think.
fab, thanks for confirming README already covers the local case!
I've split the CSRF ticket out and linked to this ticket, so I think all good now 
The CSRF error is that Play framework expects the dev to have injected an CSRF token into the form before POSTing it. This CSRF is created by the server (good explanation is here). Since the frontend is a separate project, I've just disabled CSRF here, with a comment explaining why.
I also found a couple more bugs in the backend, now fixed, and tidied up some other bits. Everything should now be ship-shape.