docker-compose up -d frontend Error

[mosheduminer]

I'm trying to set up the project following https://github.com/sirixdb/sirix-web-frontend#project-setup, when I run step 14, I get the following message:

Building frontend
ERROR: Cannot locate specified Dockerfile: Dockerfile

I am running docker toolbox on windows 10.

[welcome[bot]]

Thanks for opening your first issue 🦁 Your feedback, is the most valuable thing besides PRs 💚

[JohannesLichtenberger]

Ah thanks, I've copied the Dockerfile from the oauth2-auth branch to master. Can you retry? :-)

[mosheduminer]

Thanks, it's up and running now. Hopefully I'll be able to contribute something in the next few days.

[JohannesLichtenberger]

I think running the front-end via Docker Compose is not even necessary. So instead of running the front-end via docker-compose, maybe it is better or simpler to run with npm or yarn, such that the changes are automatically reflected. I'll change this in the READ ME I think :-)

I'm super new to the front-end stuff and currently I'm reading a book about TypeScript, so any help is super awesome :)

[JohannesLichtenberger]

Just merged the oauth2-auth branch into master. Let me know if you're running into problems, please :-)

[mosheduminer]

In regards to the recent changes:

1. The docker command to start the database was removed from the README. The frontend won't work without it, however.
2. The frontend is not running on docker, but rather on local. For those using docker toolbox (like me), docker is not localhost. This is easily solved by using requestly browser extension to redirect localhost:9443 and localhost:8080, but maybe it bears mentioning. Or at least, it took me a while to figure that out.
3. Login is not persistent. I tried figuring out how auth works, but I couldn't make it work.

[JohannesLichtenberger]

1. Yes, as it's much easier with hot code replace, so you see the changes. I'm using Ubuntu, so it works with the host network communicating with localhost. Otherwise I think
2. Hmm, what is this? Can you make a PR for the README?
3. Strange, it works for me with Firefox and Chrome. You first should be redirected to the login page. Then you click the Button to Login with Keycloak. The SirixDB REST Server redirects to Keycloak. Then you should be able to fill in the Login Form of Keycloak (user admin, pass admin). You're getting redirected back to the callback page, which does some Nuxt.js magic to extract the code and sending it via POST and the same redirect_uri to the SirixDB REST Server, which sends it to Keycloak and exchanges it for a token with the specified client_secret from the config file, which has to match the one generated from Keycloak. Hope this helps. Let me know, please. I want to make the setup as easy as possible, but somehow with 3 microservices (SirixDB HTTP Server, Keycloak and Nuxt.js/Node.js Server) it's not so trivial :(

[JohannesLichtenberger]

But maybe we could change the Dockerfile to include the whole application as a volume, rather than copying everything in the image (which might be better for the production build!?).

And regarding the Keycloak configuration I hope this helps to the the OAuth2 authentification stuff working:

[JohannesLichtenberger]

I've added list item 13 in the README. As we also need a user with all rights to communicate with the SirixDB HTTP-Server in the future :)

[mosheduminer]

• the docker server command I agree that it is far more convenient to run locally rather than with docker, but how can the frontend function without the backend running?
• Auth I'll take a look again. I wonder if this problem is related to my redirect workaround to my docker not running on localhost
• Creating a user I had just changed the settings to allow registration. I wonder if that is related to the problem?

[JohannesLichtenberger]

@mosheduminer we need to have a Keycloak server, as well as the SirixDB HTTP-Server running (for instance as docker containers). However, I have no idea how it would work without the support of the host network via Docker :(

Yes, you definitely need a user, but the redirect to Keycloak should work at least. Maybe for Windows users it might be better to start the standalone.bat from Keycloak, import the Sirix realm and add an admin user for testing. There's some documentation for the REST-API as well:

https://sirix.io/rest-api.html

I'm currently writing an article for dev.to how I got authentication with Nuxt.js + external REST API Server (SirixDB HTTP-Server) + Keycloak to run.

This might be helpful hopefully:

OAuth2 Authorization Code Flow with Nuxt.js

In general, our workflow is as follows:

• An authentication middleware controls if users should be redirected to a /login route to login in the first place
• The /login route has a simple Button, which issues a request to the SirixDB HTTP-server. Nuxt.js generates a unique, unguessable state and a redirect_uri, which Nuxt.js sends to the login route as URL parameters.
• The HTTP-Server redirects to a login-page of Keycloak and sends the two parameters as well
• Once a user correctly fills in his credentials, Keycloak redirects the browser to the given redirect_url, which Nuxt.js sends in the first place (and the SirixDB HTTP-Server)
• On the Node.js server, the Nuxt.js based front-end, a callback route is addressed by the redirect-URL
• Nuxt.js then extracts a URL parameter code and checks the state parameter for validity
• Next, Nuxt.js sends a POST HTTP-request to the /token endpoint on the SirixDB HTTP-Server with the code parameter, the redirect_uri again, which is the same callback route. Additionally it sends a response_type which we set to code, such that Nuxt.js expects a JWT access token
• The SirixDB HTTP-Server then exchanges the given code with a JWT access token from Keycloak and sends it in the HTTP response to the Nuxt.js based front-end

[mosheduminer]

@JohannesLichtenberger, sorry if I wasn't clear about the server issue. In commit ddb6f892fea764afee0fbf2f7fb28c34cbed8276 the line "Start the SirixDB HTTP-Server: sudo docker-compose up -d server" was removed. It seems to me that it was removed by accident.

As for authentication, the redirect does work. The problem is that when I try to view any page other than the callback page, I get the login page again.

[JohannesLichtenberger]

Ah, please rebuild your server image and first of all pull the changes I did to SirixVerticle in the rest-api bundle.

[JohannesLichtenberger]

I had to change a few things until I figured out what was wrong. The state parameters are mismatched I think between what Nuxt.js initially created and SirixDB created another state parameter. I think Nuxt.js should rise an error or maybe it does, but I had to look at the source code and it silently returns from the method

[JohannesLichtenberger]

Oh and the change to the README was meant like this, such that we can develope the Nuxt.js front-end without a running Docker container.

[JohannesLichtenberger]

Then start the SirixDB HTTP-server with:

sudo docker-compose up -d server

[mosheduminer]

I figured out my problem with auth. It seems that localhost:9443/token is not getting redirected. Although I did find an extension that does redirect the host, it seems that the call does not follow the redirect, but rather ends with a 307 internal redirect code.

[mosheduminer]

I fixed this by changing every mention of localhost:9443 in the source code to 192.168.99.101:9443 (my docker host). I wasn't able to change localhost:8080 in the source code, so I am using switcheroo to redirect to the docker host.

[JohannesLichtenberger]

@mosheduminer Where is localhost:8080 hardcoded?

Maybe you can change it in the sirix-conf.json file?

{
  "https.port": 9443,
  "keycloak.url": "http://localhost:8080/auth/realms/sirixdb",
  "auth.path": "http://localhost:8080/auth/realms/sirixdb/protocol/openid-connect/auth",
  "token.path": "/token",
  "client.secret": "2e54cfdf-909b-47ca-b385-4c44886f04f0",
  "oAuthFlowType" : "AUTH_CODE",
  "redirect.uri" : "http://localhost:3005/callback"
}

Here the redirect.uri shouldn't have an effect as it's specified by Nuxt.js already

[mosheduminer]

I tried that but it had no effect. I am now running into the following upon attempting to load the table:

Uncaught (in promise) TypeError: request.upload.addEventListener is not a function
    at dispatchXhrRequest (commons.app.js:171)
    at new Promise (<anonymous>)
    at xhrAdapter (commons.app.js:32)
    at dispatchRequest (commons.app.js:640)

I'm going to try to come back to this later.

[JohannesLichtenberger]

Hmm strange.

Yes, basically the whole front-end as of now is at a very early stage (and we didn't implement any SirixDB HTTP-Server API calls as of now). Don't know where this error comes from :(

I'm just reading a book about TypeScript, so that I hope I'll be able to put myself much more work into the front-end, as I think it's crucial to show what's possible with SirixDB :-)

[mosheduminer]

@JohannesLichtenberger I setup an ubuntu virtual machine, and got the same Uncaught (in promise) TypeError: request.upload.addEventListener is not a function error. Are you getting this error? Maybe something in the recent commits is causing it?

[mosheduminer]

As far as I can tell, the issue comes from mockjs - see https://github.com/nuysoft/Mock/issues/127, but I'm confused as to why this worked before. Additionally, there is a pull request from years back to solve the problem, but it was never merged.

[JohannesLichtenberger]

@mosheduminer woohoo, even setup an Ubuntu Virtual machine :-)

As of today I'm for one week in holidays without a laptop, sadly.

Maybe you have an idea about this: https://cmty.app/nuxt/auth-module/issues/c445

[mosheduminer]

@JohannesLichtenberger enjoy your holiday! On the off chance that you still want to discuss code... the solution would seem to be to implement a custom scheme as described here. If you want I can try to implement it.

[JohannesLichtenberger]

Hmm, it would be a great addition. Even more so, if this could be merged into the Nuxt.js auth module as a new official provider ;-) but if not for us it would be great, indeed. Thus, we don't need the SirixDB HTTP-Server to basically act as a proxy. Should only be needed for instance for pure SPAs, which don't have a running Node.js server. BTW maybe we can move our discussion to the forum, which is somehow very rarely used. But I think Discourse is a really great forum :-)

[JohannesLichtenberger]

The JWT tokens to be sent by Axios for manipulating or reading resources in SirixDB can then still be verified by the SirixDB HTTP-Server to check authorization :-)

[mosheduminer]

Okay I've opened a discussion on discourse.