First attempt to expose my Angular + Spring Boot in Kubernetes

I’ve got a spring boot app (backend) and angular app (frontend), protected by okta. As the setup worked locally I have containerized it with docker and it also worked locally from the backend and frontend docker containers, the only thing I had to do was forwarding the ports (spring boot: 8080:8080, angular 4200:80)

Subsequently I tried to create the probably most simple setup, namely one pod with two containers (backend and frontent) on okteto which is a pretty nice kubernetes provider. The containers got exposed nicely, I have a problem, however, by the login in the angular app. After attempting to login, I see the following:
http://localhost:4200/implicit/callback#id_token=...
in the address text box of the browser and the following error:
main-es2015.092d78be6704c3f71a6d.js:1 ERROR Error: Uncaught (in promise): AuthSdkError: Unable to retrieve OAuth redirect params cookie
However, I see no errors in my okta dev console.

I added the addresses exposed by my services to the login redirect URIs:
https://.cloud.okteto.net/login/oauth2/code/okta
https://.cloud.okteto.net/redirect
https://.cloud.okteto.net/implicit/callback

additionally to the localhost.* ones. It did not help.

and my deployment looks like this:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend
spec:
  selector:
    matchLabels:
      app: backend
  template:
    metadata:
      labels:
        app: backend
    spec:
      containers:
        - image: registry.gitlab.com/<my-app>-backend
          name: backend
          ports:
            - containerPort: 8080
              name: http
        - image: registry.gitlab.com/<my-app>-gui
          name: frontend
          ports:
            - containerPort: 80
              name: http
      imagePullSecrets:
        - name: gitlab-pull-secret
        - name: gitlab-pull-secret-gui

//backend service

apiVersion: v1
kind: Service
metadata:
  name: backend-svc
  labels:
    app: backend
  annotations:
    dev.okteto.com/auto-ingress: "true"
spec:
  type: ClusterIP
  ports:
    - port: 8080
      protocol: TCP
      targetPort: 8080
  selector:
    app: backend

//frontend service

apiVersion: v1
kind: Service
metadata:
  name: backend-svc
  labels:
    app: backend
  annotations:
    dev.okteto.com/auto-ingress: "true"
spec:
  type: ClusterIP
  ports:
    - port: 8080
      protocol: TCP
      targetPort: 8080
  selector:
    app: backend

Any idea what else do I have to do? I’m strong neither with okta nor with kubernetes, so maybe it’s about kubernetes config, not sure.

Hi,
I am not very familiar with kubernetes but looking at the error, http://localhost:4200/implicit/callback#id_token=...
even though you have added the okteto login redirect URI(s?) for your app in Okta, it would appear that somewhere within you angular/spring code there is still references to localhost:4200 for the redirect URI

Hi, there is:

const oktaConfig = {
  issuer: 'https://dev-933944.okta.com/oauth2/default',
  redirectUri: 'http://localhost:4200/implicit/callback',
  clientId: '0oa213871t9STk5R8357',
  pkce: false
};

But then what do I have to enter as a redirectUri to make it work both on my local machine and in my remote kubernetes instance? does it have to be some kind of external variable?

What versions of the Okta auth and angular SDKs are you using? Are redirecting to Okta to signin, using a self hosted widget?

Since this works with a local docker deployment, you might try going through a full login sequence where you capture all the network calls in a .har file. Then go through the exact same sequence for the kubernetes deployment and compare .har files.

If you don’t see anything that helps isolate the cause (repeated network calls for example)I suggest opening a case with support by mailing to developers@okta.com. This way the .har files could be attached along with gathering more information about your particular setup.

Not sure if I understand everything, but that’s what I find in my package lock.json:

"@okta/configuration-validation": {
  "version": "0.4.1",
  "resolved": "https://registry.npmjs.org/@okta/configuration-validation/-/configuration-validation-0.4.1.tgz",
  "integrity": "sha512-p8QcApCSyAXtlyB7p7jXkAkcTedvK9WFkmEduVA3XxQQVs3njxD9vTooFj4+AF6WNRIuGOis/utL7m0BzYkyVw=="
},
"@okta/okta-angular": {
  "version": "1.4.0",
  "resolved": "https://registry.npmjs.org/@okta/okta-angular/-/okta-angular-1.4.0.tgz",
  "integrity": "sha512-sob0dx37pA8vZK/q+qeXYx1SfjftVqX4fOR8MOPcR27S6RV75X045bSWhdmXVSZxwyQEwY6mfnjK1k0Wj7bSDg==",
  "requires": {
    "@okta/configuration-validation": "^0.4.1",
    "@okta/okta-auth-js": "^2.11.2",
    "tslib": "^1.9.0"
  }
},
"@okta/okta-auth-js": {
  "version": "2.13.0",
  "resolved": "https://registry.npmjs.org/@okta/okta-auth-js/-/okta-auth-js-2.13.0.tgz",
  "integrity": "sha512-0h98/ceSmcyfpK8K8pIil3e//hC5W45uBh9CwL3I0CkcxEwmfmbGE0o59hiTDKqaZh9teVT584qIVbN6k3nL6A==",
  "requires": {
    "Base64": "0.3.0",
    "cross-fetch": "^3.0.0",
    "js-cookie": "2.2.0",
    "node-cache": "^4.2.0",
    "q": "1.4.1",
    "reqwest": "2.0.5",
    "tiny-emitter": "1.1.0",
    "xhr2": "0.1.3"
  }
},
"@okta/okta-signin-widget": {
  "version": "3.8.2",
  "resolved": "https://registry.npmjs.org/@okta/okta-signin-widget/-/okta-signin-widget-3.8.2.tgz",
  "integrity": "sha512-gMJePv91ZcJ/uvU43HywIOs7YplyRr1UU6VlH5C3LaW4AQ5Egl7FQsUYgNo3nJ2lXZ4LTXe73eKOtadFENXOFA==",
  "requires": {
    "babel-polyfill": "^6.23.0",
    "babel-runtime": "^6.26.0",
    "cross-fetch": "^3.0.4",
    "eslint-plugin-jasmine": "^4.1.0",
    "fsevents": "*",
    "handlebars": "^4.5.1",
    "q": "1.4.1",
    "u2f-api-polyfill": "0.4.3",
    "underscore": "1.8.3"
  },
  "dependencies": {
    "handlebars": {
      "version": "4.7.3",
      "resolved": "https://registry.npmjs.org/handlebars/-/handlebars-4.7.3.tgz",
      "integrity": "sha512-SRGwSYuNfx8DwHD/6InAPzD6RgeruWLT+B8e8a7gGs8FWgHzlExpTFMEq2IA6QpAfOClpKHy6+8IqTjeBCu6Kg==",
      "requires": {
        "neo-async": "^2.6.0",
        "optimist": "^0.6.1",
        "source-map": "^0.6.1",
        "uglify-js": "^3.1.4"
      }
    },
    "source-map": {
      "version": "0.6.1",
      "resolved": "https://registry.npmjs.org/source-map/-/source-map-0.6.1.tgz",
      "integrity": "sha512-UjgapumWlbMhkBgzT7Ykc5YXUT46F0iKu8SGXq0bcwP5dz/h0Plj6enJqjz1Zbq2l5WaqYnrVbwWOWMyF3F47g=="
    }
  }
},
"@oktadev/schematics": {
  "version": "1.6.0",
  "resolved": "https://registry.npmjs.org/@oktadev/schematics/-/schematics-1.6.0.tgz",
  "integrity": "sha512-Zg2vImCi5sQXO4dt/6fIMf7S5cB/62C4dxdCI7pNSNqO+wmKpLwe1ymCIbpkcFEOdwA1vAuT0qDrggpFDb37sg==",
  "requires": {
    "@angular-devkit/core": "9.0.7",
    "@angular-devkit/schematics": "9.0.7",
    "@schematics/angular": "9.0.7",
    "rxjs": "6.5.4",
    "schematics-utilities": "2.0.0"
  },

I might try the har files, but I kind of find it confusing what “localhost” is in this context. I guess I really need some expertise from someone who knows kubernetes, something really tells me it’s as simple as somehow externalizing the redirect address value or doing some fancy network rerouting.

In fact I have solved the login problem, had to replace localhost:4200 with window.location.origin and it worked for the Angular app. Now the next step is to make it properly work with the Spring boot app:)

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.