Dashboard not working due to wrong wp-admin URL

I have installed a WordPress site and I configured it behind a reverse proxy with site URL – https://example.com/blog

Problem:
I can reach the admin dashboard page at https://example.com/blog/wp-login.php however as I login the dashboard URL is as follows https://example.com/wp-admin ie. it does not have /blog/ in the URL, I cannot go further as the link becomes http://example.com/wp-admin instead of http://example.com/blog/wp-admin.

I read somewhere to change the Request Uri or add a filter but don’t know where to add the code

kubernetes – How to properly configure access to kubernees dashboard behind nginx ingress

I’m trying to configure nginx ingress to access several services, like this:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-monit
spec:
  rules:
  - host: grafana.localhost
    http:
      paths:
      - path: /
        backend:
          serviceName: prometheus-grafana
          servicePort: 80
  - host: kubernetes-dashboard.localhost
    http:
      paths:
      - path: /
        backend:
          serviceName: kubernetes-dashboard
          servicePort: 80

I’ve access to the grafana service without any problems, my issue is with kubernetes-dashboard.
I’ve already configured kubernetes-dashboard to allow HTTP traffic with this configuration

kind: Service
apiVersion: v1
metadata:
  labels:
    k8s-app: kubernetes-dashboard
  name: kubernetes-dashboard
  namespace: monit
spec:
  ports:
    - port: 80
      targetPort: 9090
  selector:
    k8s-app: kubernetes-dashboard

---

kind: Deployment
apiVersion: apps/v1
metadata:
  labels:
    k8s-app: kubernetes-dashboard
  name: kubernetes-dashboard
  namespace: monit
spec:
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      k8s-app: kubernetes-dashboard
  template:
    metadata:
      labels:
        k8s-app: kubernetes-dashboard
    spec:
      containers:
        - name: kubernetes-dashboard
          image: kubernetesui/dashboard:v2.0.0-beta8
          imagePullPolicy: Always
          ports:
            - containerPort: 9090
              protocol: TCP
          args:
            - --namespace=monit
            - --insecure-bind-address=0.0.0.0
            - --insecure-port=9090
            - --enable-insecure-login
            # Uncomment the following line to manually specify Kubernetes API server Host
            # If not specified, Dashboard will attempt to auto discover the API server and connect
            # to it. Uncomment only if the default does not work.
            # - --apiserver-host=http://my-address:port
          volumeMounts:
            - name: kubernetes-dashboard-certs
              mountPath: /certs
              # Create on-disk volume to store exec logs
            - mountPath: /tmp
              name: tmp-volume
          livenessProbe:
            httpGet:
              scheme: HTTP
              path: /
              port: 9090
            initialDelaySeconds: 30
            timeoutSeconds: 30
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            runAsUser: 1001
            runAsGroup: 2001
      volumes:
        - name: kubernetes-dashboard-certs
          secret:
            secretName: kubernetes-dashboard-certs
        - name: tmp-volume
          emptyDir: {}
      serviceAccountName: kubernetes-dashboard
      nodeSelector:
        "beta.kubernetes.io/os": linux
      # Comment the following tolerations if Dashboard must not be deployed on master
      tolerations:
        - key: node-role.kubernetes.io/master
          effect: NoSchedule

I;ve also a valid token which I can use to access kubernetes dashboard when I use ClusterIP.
However when I access it through ngress I cannot go over the login page even with valid token (see screenshot).

enter image description here

I looked into Nginx logs for problems/errors but everything seemed fine

$ kubectl logs -n monit ingress-nginx-controller-bbdc786b4-6nl9h  -f
192.168.65.3 - - (03/Jun/2020:02:03:13 +0000) "GET /api/v1/csrftoken/login HTTP/1.1" 200 85 "http://kubernetes-dashboard.localhost/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.61 Safari/537.36" 479 0.001 (monit-kubernetes-dashboard-80) () 10.1.0.123:9090 85 0.001 200 59fc952888dfadf0223740c31e562ef8
192.168.65.3 - - (03/Jun/2020:02:03:13 +0000) "POST /api/v1/login HTTP/1.1" 200 1508 "http://kubernetes-dashboard.localhost/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.61 Safari/537.36" 1545 0.005 (monit-kubernetes-dashboard-80) () 10.1.0.123:9090 1508 0.005 200 241388246b11031765557475bea603ff
192.168.65.3 - - (03/Jun/2020:02:03:13 +0000) "GET /api/v1/plugin/config HTTP/1.1" 200 185 "http://kubernetes-dashboard.localhost/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.61 Safari/537.36" 477 0.003 (monit-kubernetes-dashboard-80) () 10.1.0.123:9090 185 0.003 200 45371469793ce4f35c45dec70530bea0
192.168.65.3 - - (03/Jun/2020:02:03:13 +0000) "GET /api/v1/login/status HTTP/1.1" 200 108 "http://kubernetes-dashboard.localhost/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.61 Safari/537.36" 476 0.001 (monit-kubernetes-dashboard-80) () 10.1.0.123:9090 108 0.001 200 49171f5e9316a2d6da883d1c4f0b50df
192.168.65.3 - - (03/Jun/2020:02:03:13 +0000) "GET /api/v1/login/status HTTP/1.1" 200 108 "http://kubernetes-dashboard.localhost/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.61 Safari/537.36" 476 0.001 (monit-kubernetes-dashboard-80) () 10.1.0.123:9090 108 0.001 200 c69b9d166f1527f00e7cd175696ec8c7
192.168.65.3 - - (03/Jun/2020:02:03:13 +0000) "GET /api/v1/login/status HTTP/1.1" 200 108 "http://kubernetes-dashboard.localhost/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.61 Safari/537.36" 476 0.001 (monit-kubernetes-dashboard-80) () 10.1.0.123:9090 108 0.001 200 1f9c27ca407bca57dcc0c26bca65be58

What am I missing in my ingress configuration?

web app – What are the best macro-areas for an Editing Tool Dashboard?

I am a designer, working on an editing tool, that allows you to create presentations.
You can collaborate on these presentations with other users of the platform. I wonder what are the clearest, most simple macro-areas to find on the dashboard.
So far I have: All Files, Shared with me ( single presentations shared by peers) and Folders ( I create a folder to group similar presentations, inside this section I see other folders that have been shared with me). Does this make sense? Are there any other ways? more dynamic and fluid, less structured? Thanks a lot

web app – Dashboard design, are there any good alternatives to side nav?

I am trying to create a user profile dashboard for an application. The user creates the media asset which is saved under All files, he/she should be able to organize these files somehow ( workspaces/folders/projects, you name it), from the web I see the most common solution is to have a side bar where user creates folders in which he can drag the assets created. I guess is so commonly used because the folders are always within reach but are there any other creative alternatives to a side nav for application file management? Thanks

oauth2 – How to integrate multiple services via API’s into a single dashboard on a per-user basis with SSO?

so my project is that I’d like to pull data from a bunch of different services/API’s and show them in a single dashboard. SSO is a requirement so I want to make sure the user doesn’t have to put in their password over and over.

The system already has SAML2.0 set up with ADFS which is configured as the identity provider for all the services.

The issue is that when a user uses SAML to log into a service, they leave my dashboard app and don’t get any of the user permissions for that service. For example, say the user is trying to access Gitlab and they only have access to a certain number of projects, unless they go into gitlab and generate a user API key and copy/paste it into my dashboard app, I can’t get that user’s permissions when making API calls.

From my research, it sounds like using OAuth2.0 is the solution to this; set up ADFS to generate tokens for a user (as the Authorization server) and then integrate it with applications that use OAuth2.0 (which would be the resource servers) and my dashboard app would be basically a client hanging on to the tokens. This would enable me to make API calls with scoped permissions.

Does this sound like a good idea? Instinctually, I feel that this has got to be a common problem that’s been solved many times before but I am not formulating the Google/Stackoverflow searches for the solution.

user behavior – Any link to some usability study on dashboard menu?

I am working on designing dashboard screens for a directory of tiny house enthusiasts(the site will also have social features like making friends, following people etc.)

Here’s a screen that I designed – https://imgur.com/a/RzP9SgP

There are items on the left panel and once someone selects an item, it shows the sub-items on the main screen.

Is there any usability study that points out what pattern works for dashboard menus (like having sub-items also on the left panel or showing it on the main screen itself)?

dashboard – How to show progress bar and percentage value in a compact space?

By trying to keep the number in the bar, users are potentially getting information less quickly, which goes against what a dashboard seeks to achieve: Insight of status at a glance.

You can get more contrast by pulling the number up, and making it larger. Then, display progress as a contrasting line, reserving the color only for the values that are progressing.

enter image description here

I’m not sure what your other constraints are, but if the purple needs more contrast, you can darken the text and the bar, but they can work visually as one unit.

It’s easier to read a prominent ‘7%’, than to calculate the fill position in the progress bar. Your current design is the other way around: the bar is prominent, but I strain to read the text.

Rather than two purple hues, gray represents the absence of completion.

Architecture – design a BI dashboard system – data aggregation logic in the frontend or backend?

I work with a system that is very similar to a BI dashboard. For example, suppose the dashboard shows some of the company's business metrics, such as B. Sales, Refund, Number of Orders, Average Order Value, etc.

The data for one year is displayed on the front end. The daily value for one year is currently displayed in a line chart. However, later the user will be able to select various aggregation options, e.g. For example, data is aggregated by year, week, month, etc. (or after 7 days, 14 days, etc.). Yes, this is not yet known point). In the backend we use a Big Data Warehouse solution (SQL) and a Node.js server

Now I'm thinking about 3 options and I'm not sure which approach to take. If you want to share some experiences / insights, this will be greatly appreciated!

1) The aggregation logic in the backend, especially the data layer, basically performs the aggregation in SQL queries.

pro: 1) fast 2) scales well as the data size grows (let's say we show 3 year data, more metrics)

con: 1) If the logic of query aggregation changes (e.g., from calendar month / week to consecutive x days), most queries may be rewritten (may not be true if this is the case). 2) Need more work to set up a solid test.

2) Aggregation logic in the backend, especially on the application layer. Basically, the query returns daily data points and the application processes the aggregation logic.

pro: 1) easier to change if the aggregation logic changes (relatively)

con: 1) slower than this in the data layer (more network traffic, voice performance difference, more load on the server) 2) worse scaled compared to the data layer approach

3) Aggregation logic in the frontend, most diagram libraries support various aggregation scenarios. Basically, api returns all daily data points.

pro: 1) very flexible if the aggregation logic changes.

con: 1) slow (network traffic, browser engine, we also support mobile, so it can be very bad on mobile) 2) scales the wort