Failed authentication after period of time

I generated a react app from the reference UI, and I am using npm start to start the react app. The react app works at first, but after a few hours, when I type some text, I am asked for a username/password because authentication fails. However, when I go to the server that hosts app-search, and then I try to search something again from the react app, it works. After a few hours, the search fails again.

Is there a setting that fixes this issue?




Config Files:
# ======================== Elasticsearch Configuration =========================
...
# ---------------------------------- Cluster -----------------------------------
#
# Use a descriptive name for your cluster:
#
#cluster.name: my-application
#
# ------------------------------------ Node ------------------------------------
#
# Use a descriptive name for the node:
#
#node.name: node-1
#
# Add custom attributes to the node:
#
#node.attr.rack: r1
#
# ----------------------------------- Paths ------------------------------------
#
# Path to directory where to store the data (separate multiple locations by comma):
#
path.data: /elastic/lib/elasticsearch
#
# Path to log files:
#
path.logs: /elastic/log/elasticsearch
#
# ----------------------------------- Memory -----------------------------------
#
# Lock the memory on startup:
#
# bootstrap.memory_lock: true
#
# Make sure that the heap size is set to about half the memory available
# on the system and that the owner of the process is allowed to use this
# limit.
#
# Elasticsearch performs poorly when the system is swapping the memory.
#
# ---------------------------------- Network -----------------------------------
#
# Set the bind address to a specific IP (IPv4 or IPv6):
#
#network.host: 192.168.0.1
#
# Set a custom port for HTTP:
#
#http.port: 9200
#
# For more information, consult the network module documentation.
#
# --------------------------------- Discovery ----------------------------------
#
# Pass an initial list of hosts to perform discovery when this node is started:
# The default list of hosts is ["127.0.0.1", "[::1]"]
#
#discovery.seed_hosts: ["host1", "host2"]
#
# Bootstrap the cluster using an initial set of master-eligible nodes:
#
# cluster.initial_master_nodes: ["node-1"]
#
# For more information, consult the discovery and cluster formation module documentation.
#
# ---------------------------------- Gateway -----------------------------------
#
# Block initial recovery after a full cluster restart until N nodes are started:
#
#gateway.recover_after_nodes: 3
#
# For more information, consult the gateway module documentation.
#
# ---------------------------------- Various -----------------------------------
#
# Require explicit names when deleting indices:
#
#action.destructive_requires_name: true
#
action.auto_create_index:
".app-search-*-logs-*,-.app-search-*,+*"

## ===================== Elastic App Search Configuration =====================
#
# NOTE: Elastic App Search comes with reasonable defaults.
# Before adjusting the configuration, make sure you understand what you
# are trying to accomplish and the consequences.
#
# NOTE: For passwords, the use of environment variables is encouraged
# to keep values from being written to disk, e.g.
# elasticsearch.password: ${ELASTICSEARCH_PASSWORD:changeme}
#
# ---------------------------------- Elasticsearch ----------------------------
...
# ------------------------------- Hosting & Network ---------------------------
#
# Define the exposed URL at which users will reach App Search.
# Defaults to localhost:3002 for testing purposes.
# Most cases will use one of:
#
# * An IP: http://255.255.255.255
# * A FQDN: http://example.com
# * Shortname defined via /etc/hosts: http://app-search.search
#
app_search.external_url: http://ld-dbn-boref020:3002
#
# Web application listen_host and listen_port.
# Your application will run on this host and port.
#
# * app_search.listen_host: Must be a valid IPv4 or IPv6 address.
# * app_search.listen_port: Must be a valid port number (1-65535).
#
app_search.listen_host: 10.31.150.40
app_search.listen_port: 3002
#
# Background worker monitoring.
# Diagnostic information will be served on `app_search.monitoring_port`.
#
# * app_search.monitoring_enabled: Set to false to disable monitoring.
# * app_search.monitoring_port: Must be a valid port number (1-65535).
#
#app_search.monitoring_enabled: true
#app_search.monitoring_port: 3003
#
# ------------------------------ Authentication -------------------------------
...
# ---------------------------------- Email -----------------------------------
...
# ----------------------------------- APIs ------------------------------------
...
# ----------------------------- Diagnostics report ----------------------------
...
# ---------------------------------- Logging ----------------------------------
...
# ------------------------------- TLS/SSL -------------------------------
...
# ---------------------------------- Session ----------------------------------
#
# Set key to persist user sessions through process restarts.
#
secret_session_key: ...
#

Hello, Ayan!

Welcome to the community. :tada:

Before I dig into this, can you please confirm which version of App Search you're running?

Thanks!

Kellen

Yes, I am using app-search-7.2.0 with elasticsearch-7.2.0.

Thanks,
Andy

Hi @ayan

I think this only happens when you run App Search and the React app Reference UI on the same host. Are they running on the same host? If yes, is this an intentional choice?

I suspect that Reference UI tries to authenticate with the App Search cookie even though we actually transmit the search key in the request. Using different hosts or browsers should help with this.

Ah yes, I am running them on the same host. I am doing that because it was easiest to start development.

Is there an easy way to disable cookie authentication w/ the Reference UI instead?

Thanks a ton!
Andy

I have seen this happen on from the react reference ui on a hosted solution that is not on the same server with a 7.3 version. As soon I open a browser to the admin ui on the self hosted solution it seems to work. I have been thinking it may be due to redux state management being used on client side.