Login page loops indefinitely

Hi,
Last week, I installed Superset using the Docker Compose method.
I did the following steps exactly:
git clone https://github.com/apache/superset.git
cd superset
sudo docker-compose -f docker-compose-non-dev.yml pull
sudo docker-compose -f docker-compose-non-dev.yml up
After executing these commands, I accessed Superset using the following URL: http://<IP_ADDRESS>:8088/
Username: admin
Password: admin
Everything was working fine : I was able to use Superset without any issue, it was working like a charm.
Today, I rolled back the server to a snapshot taken before the installation of Superset.
However, after having performed the exact same steps as last week, I'm encountering a problem : I can access the login screen, but when I enter the login (admin) and password (admin), I am stuck on the same page (looping on the same login screen).
I am certain that I am following the same steps as last week.
Do you have any ideas about what might be causing the issue?
Many thanks in advance for your help!
How to reproduce the bug

Install docker & docker compose
Install apache superset with docker compose (see details above)
Go to http://ip_address_of_server:8088
Fill in "admin" in the username field
Fill in "admin" in the password field
Click "Sign in"

Expected results
Entering superset application
Actual results
Looping to the same login page
Environment

browser type and version: Chrome, Firefox (last versions)
superset version: last version
python version: 3.10.6

Checklist
Make sure to follow these steps before submitting your issue - thank you!

[ ] I have checked the superset logs for python stacktraces and included it here as text if there are any.
[ ] I have reproduced the issue with at least the latest released version of superset.
[ ] I have checked the issue tracker for the same issue and I haven't found one similar.

Many thanks for your help.
Julien

If you aren't specifying a certain image in your docker-compose.yml file, it's probably defaulting to latest which almost certainly changed between your two installations.  Try replacing the reference to latest with 2.1.0 and see if that helps?

Could also be related to https://github.com/apache/superset/discussions/24435#discussioncomment-6282883

Thank you for your feedback @sfirke, but I'm afraid, it still doesn't work.... :( :(
Here is what I've done to try version 2.1.0 (maybe there is something that I did not not apply correctly) :
First of all, rollback to fresh install of the server
And then, applied these commands :
git clone https://github.com/apache/superset.git
cd superset
git checkout 2.1.0
TAG=2.1.0 sudo docker compose -f docker-compose-non-dev.yml pull
TAG=2.1.0 sudo docker compose -f docker-compose-non-dev.yml up
But the issue remains the same : I'm able to display the login screen, but when I enter admin/admin, I loop to the same screen.
What I've also noticed (if that could give a clue), is that the settings / version menu states : 0.0.0-dev
These displays only with Chrome (not with Firefox).
Strange....

I just edited docker-compose-non-dev.yml to specify image version at line
x-superset-image: &superset-image apache/superset:2.1.0

Then do not forgot to remove containers and pull images

Many thanks @ww7 !! :)
It's now working perfectly again with version 2.1.0 !!
So it now seems obvious that it's a bug with the latest version.
Just to learn from that experience : how could I get a list of the history of the different versions that are released?
On docker hub, there are some "strange" number versions, like "eb42fa7a2e21d5d4d69a6e8a9787dc8ea1dd6348-py310"
I'm just wondering how I could see the version history like 2.0.0, 2.1.0, etc...

@julien92git just scroll down or search/filter versions, there also 2.10 and 3.0.0rc1 etc
"Strange" numbers it's a "randomized" tag (kind of hash of image) because images deployed frequently from source code, probably after every Github commit.

many thanks again @ww7 , much clearer for me now!
I assume version 3.0.0 will include the fix for that bug

@julien92git probably dev's would post addition information about CSRF for non-dev setup.

I encountered the same issue. I deployed Superset on a server using Docker Compose. Accessing localhost on the server interface works fine, but when I try to access it via the IP address, it keeps showing the login page and the browser continuously redirects.

However, the issue I'm experiencing is slightly different from the description above.
For example, my Mac's IP address is <IP_ADDRESS>.
I have deployed Superset on Docker on my Mac.
When I access it using localhost:8088, everything works fine.
However, when I try to access it using <IP_ADDRESS>:8088, it gets stuck in a login page loop with continuous 302 redirects.
@ww7  cloud you please advise on how to fix this situation?

@xddpool I think reverse-proxy with SSL (Nginx/Apache/Caddy/HAproxy etc) can solve this
Are you sure deployed apache/superset:2.1.0 ?

When will this issue be fixed

Hi, can you try changing your TALISMAN_ENABLED config to False?

If you aren't specifying a certain image in your docker-compose.yml file, it's probably defaulting to latest which almost certainly changed between your two installations. Try replacing the reference to latest with 2.1.0 and see if that helps?

Solved my problem perfectly ! 💯

If you use <IP_ADDRESS>:8088 => change to localhost:8088

i used 2.1.0 and i get the same issue:
2023-08-02 18:56:48,036:INFO:flask_wtf.csrf:The CSRF session token is missing.
Refresh CSRF token error
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/flask_wtf/csrf.py", line 261, in protect
    validate_csrf(self._get_csrf_token())
  File "/usr/local/lib/python3.8/site-packages/flask_wtf/csrf.py", line 103, in validate_csrf
    raise ValidationError("The CSRF session token is missing.")
wtforms.validators.ValidationError: The CSRF session token is missing.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1515, in full_dispatch_request
    rv = self.preprocess_request()
  File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1857, in preprocess_request
    rv = self.ensure_sync(before_func)()
  File "/usr/local/lib/python3.8/site-packages/flask_wtf/csrf.py", line 229, in csrf_protect
    self.protect()
  File "/usr/local/lib/python3.8/site-packages/flask_wtf/csrf.py", line 264, in protect
    self._error_response(e.args[0])
  File "/usr/local/lib/python3.8/site-packages/flask_wtf/csrf.py", line 307, in _error_response
    raise CSRFError(reason)
flask_wtf.csrf.CSRFError: 400 Bad Request: The CSRF session token is missing.
2023-08-02 18:56:48,037:WARNING:superset.views.base:Refresh CSRF token error
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/flask_wtf/csrf.py", line 261, in protect
    validate_csrf(self._get_csrf_token())
  File "/usr/local/lib/python3.8/site-packages/flask_wtf/csrf.py", line 103, in validate_csrf
    raise ValidationError("The CSRF session token is missing.")
wtforms.validators.ValidationError: The CSRF session token is missing.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1515, in full_dispatch_request
    rv = self.preprocess_request()
  File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1857, in preprocess_request
    rv = self.ensure_sync(before_func)()
  File "/usr/local/lib/python3.8/site-packages/flask_wtf/csrf.py", line 229, in csrf_protect
    self.protect()
  File "/usr/local/lib/python3.8/site-packages/flask_wtf/csrf.py", line 264, in protect
    self._error_response(e.args[0])
  File "/usr/local/lib/python3.8/site-packages/flask_wtf/csrf.py", line 307, in _error_response
    raise CSRFError(reason)
flask_wtf.csrf.CSRFError: 400 Bad Request: The CSRF session token is missing.

I have the same issue.  I have TALISMAN_ENABLE as False in config.py.
Do you want Talisman enabled?
#TALISMAN_ENABLED = utils.cast_to_boolean(os.environ.get("TALISMAN_ENABLED", True))
TALISMAN_ENABLED = utils.cast_to_boolean(os.environ.get("TALISMAN_ENABLED", False))
(I comment out the original line, and then copy and paste into a new line and change True to False).
Type in the username and password as specified, and voila, it goes right back to the same login page.
I am running the docker-compose-non-dev.yml (but I get the same result with the regular docker-compose).  I do a have a SECRET_KEY defined in the superset_config.py file.  I have defined it two ways.  The first time, I defined it AFTER I'd already brought Superset up.  The second time, I defined it before I brought it up.  It does not matter either way, it still goes right back to the login page.
I know the init script is running based on the information below, so the admin user is created and available.
######################################################################
superset_init           |
superset_init           |
superset_init           | Init Step 1/4 [Complete] -- Applying DB migrations
superset_init           |
superset_init           |
superset_init           | ######################################################################
superset_init           |
superset_init           |
superset_init           | ######################################################################
superset_init           |
superset_init           |
superset_init           | Init Step 2/4 [Starting] -- Setting up admin user ( admin / admin )
superset_init           |
superset_init           |
superset_init           | ######################################################################
superset_init           |
superset_worker         | [2023-08-06 14:07:04,434: INFO/MainProcess] Connected to redis://redis:6379/0
superset_worker         | [2023-08-06 14:07:04,435: INFO/MainProcess] mingle: searching for neighbors
superset_init           | logging was configured successfully
superset_init           | 2023-08-06 14:07:05,241:INFO:superset.utils.logging_configurator:logging was configured successfully
superset_init           | 2023-08-06 14:07:05,243:INFO:root:Configured event logger of type <class 'superset.utils.log.DBEventLogger'>
superset_worker         | [2023-08-06 14:07:05,439: INFO/MainProcess] mingle: all alone
superset_worker         | [2023-08-06 14:07:05,445: INFO/MainProcess] celery@66f27eab0157 ready.
superset_init           | Loaded your LOCAL configuration at [/app/docker/pythonpath_dev/superset_config.py]
superset_init           | Recognized Database Authentications.
superset_init           | Admin User admin created.
superset_init           |
superset_init           | ######################################################################
superset_init           |
superset_init           |
superset_init           | Init Step 2/4 [Complete] -- Setting up admin user
superset_init           |
superset_init           |
superset_init           | ######################################################################
superset_init           |
superset_init           |
superset_init           | ######################################################################
superset_init           |
superset_init           |
superset_init           | Init Step 3/4 [Starting] -- Setting up roles and perms
superset_init           |
superset_init           |
superset_init           | ######################################################################
Step 4 was also successful, I just excluded it here to save on my novella.
When I changed the secret key AFTER deployment, I did follow the instructions in the Superset documentation to Rotate in a new SECRET_KEY. (including viewing the existing from the superset shell inside of the superset container.
Am I setting the TALISMAN_ENABLED incorrect?

WTF_CSRF_ENABLED = False
TALISMAN_ENABLED=False
Worked for me!

WTF_CSRF_ENABLED = False TALISMAN_ENABLED=False Worked for me!

I found this in the superset repo https://github.com/apache/superset/blob/master/.github/workflows/ecs-task-definition.json
Seems like even there own code suggest setting TALISMAN_ENABLED = False

If you aren't specifying a certain image in your docker-compose.yml file, it's probably defaulting to latest which almost certainly changed between your two installations. Try replacing the reference to latest with 2.1.0 and see if that helps?

Solved my problem perfectly ! 💯
work for me:)

It works with edit of docker-compose-non-dev.yml to specify image version at line
x-superset-image: &superset-image apache/superset:2.1.0

Then do not forgot to rm containers and pull the image specified
@julien92git you messed things, you need to use not a Github tags and releases because you don't build images himself, but using images from Docker Hub repository.
Also, previously you updated files in container, that lost after images pull and containers recreation.

it work for me

WTF_CSRF_ENABLED = False TALISMAN_ENABLED=False Worked for me!

What if you need this setting to be true?

TALISMAN_ENABLED=False
Worked for me

However, when I try to access it using <IP_ADDRESS>:8088, it gets stuck in a login page loop with continuous 302 redirects.

I am booting up a new instance of Superset, using stable version 2.1.0 that I have running elsewhere in production.  I'm without my normal working Application Gateway right now that goes in front of my production instance and I got stuck in this loop of redirects, even with WTF_CSRF_ENABLED = False and TALISMAN_ENABLED=False.
I set SESSION_COOKIE_SAMESITE = 'Lax' and SESSION_COOKIE_SECURE = False and that got me able to log in.  In my normal production setup these are 'None' for SAMESITE and True for Secure.  I also have WTF_CSRF_ENABLED and TALISMAN_ENABLED as True there.
I think this advice from @ww7 above is on track:

I think reverse-proxy with SSL (Nginx/Apache/Caddy/HAproxy etc) can solve this

But I wonder if we could avoid this by setting SESSION_COOKIE_SAMESITE, SESSION_COOKIE_SECURE, TALISMAN_ENABLED and WTF_CSRF_ENABLED to a combination that works out of the box.  Or if that's undesirable then we should document this better.

Hi, I am facing this same error on superset 3.0.0 (non-dev) which is NOT running behind any proxy and is on http, (not https). I have tried various combinations of these parameters SESSION_COOKIE_HTTPONLY, SESSION_COOKIE_SECURE, SESSION_COOKIE_SAMESITE, WTF_CSRF_ENABLED, and TALISMAN_ENABLED. I am still facing the same error and stuck in a login loop. Which combination is supposed to be right for my use case ?

Could someone experiencing this issue please try adding "session_cookie_secure": False to their TALISMAN_CONFIG and seeing if that helps?  From https://github.com/apache/superset/issues/25374#issuecomment-1735702931.

Hi, I am facing this same error on superset 3.0.0 (non-dev) which is NOT running behind any proxy and is on http, (not https). I have tried various combinations of these parameters SESSION_COOKIE_HTTPONLY, SESSION_COOKIE_SECURE, SESSION_COOKIE_SAMESITE, WTF_CSRF_ENABLED, and TALISMAN_ENABLED. I am still facing the same error and stuck in a login loop. Which combination is supposed to be right for my use case ?

Same here. The only think that work is setting in docker-compose-non-dev.yml version 2.1.0

Hi all,
I have installed superset using official docker-compose installation on my local machine(Installed version 3.0.0). And since the official installation doesn't backup the superset metadata, it is recommended either to change the SQLALCHEMY_DATABASE_URI to a managed database or backup the data regularly yourself. The former didn't work for me (problem was the same i.e. I can access the superset login page but after entering the username and password (admin, admin) it results in invalid login. So, after consulting with my senior he told me to use bind mounting method so as to manage the data ourselves. Therefore, I have made the following changes in the non-dev yml file:
x-superset-image: &superset-image apachesuperset.docker.scarf.sh/apache/superset:3.0.0
x-superset-depends-on: &superset-depends-on

db
redis
x-superset-volumes:
&superset-volumes # /app/pythonpath_docker will be appended to the PYTHONPATH in the final container
./docker:/app/docker

- superset_home:/app/superset_home
Changes made by me for bind mount

type: bind
source: ./data
target: /app/superset_home

After these changes superset was running smoothly.
Now, I have to deploy it on a ubuntu vm , so I have transferred the superset directory to the vm and upon running the container the superset_init is not initializing (Error is below). Can someone please help what I am doing wrong?
FYI: I have updated the SECRET_KEY in superset_config.py file.
WARN[0000] The "CYPRESS_CONFIG" variable is not set. Defaulting to a blank string.
WARN[0000] The "CYPRESS_CONFIG" variable is not set. Defaulting to a blank string.
superset_app          | Skipping local overrides
superset_app          | Starting web app...
superset_app          | [2023-10-06 10:21:41 +0000] [7] [INFO] Starting gunicorn 20.1.0
superset_app          | [2023-10-06 10:21:41 +0000] [7] [INFO] Listening at: http://<IP_ADDRESS>:8088 (7)
superset_app          | [2023-10-06 10:21:41 +0000] [7] [INFO] Using worker: gthread
superset_app          | [2023-10-06 10:21:41 +0000] [8] [INFO] Booting worker with pid: 8
superset_app          | logging was configured successfully
superset_app          | 2023-10-06 10:21:48,705:INFO:superset.utils.logging_configurator:logging was configured successfully
superset_app          | 2023-10-06 10:21:48,713:INFO:root:Configured event logger of type <class 'superset.utils.log.DBEventLogger'>
superset_app          | /usr/local/lib/python3.9/site-packages/flask_limiter/extension.py:293: UserWarning: Using the in-memory storage for tracking rate limits as no storage was explicitly specified. This is not recommended for production use. See: https://flask-limiter.readthedocs.io#configuring-a-storage-backend for documentation about configuring the storage backend.
superset_app          |   warnings.warn(
superset_worker_beat  | Skipping local overrides
superset_worker_beat  | Starting Celery beat...
superset_worker_beat  | logging was configured successfully
superset_worker_beat  | 2023-10-06 10:21:48,502:INFO:superset.utils.logging_configurator:logging was configured successfully
superset_worker_beat  | 2023-10-06 10:21:48,506:INFO:root:Configured event logger of type <class 'superset.utils.log.DBEventLogger'>
superset_worker_beat  | /usr/local/lib/python3.9/site-packages/flask_limiter/extension.py:293: UserWarning: Using the in-memory storage for tracking rate limits as no storage was explicitly specified. This is not recommended for production use. See: https://flask-limiter.readthedocs.io#configuring-a-storage-backend for documentation about configuring the storage backend.
superset_worker_beat  |   warnings.warn(
superset_worker       | Skipping local overrides
superset_worker       | Starting Celery worker...
superset_worker       | logging was configured successfully
superset_worker       | 2023-10-06 10:21:48,243:INFO:superset.utils.logging_configurator:logging was configured successfully
superset_worker       | 2023-10-06 10:21:48,252:INFO:root:Configured event logger of type <class 'superset.utils.log.DBEventLogger'>
superset_worker       | /usr/local/lib/python3.9/site-packages/flask_limiter/extension.py:293: UserWarning: Using the in-memory storage for tracking rate limits as no storage was explicitly specified. This is not recommended for production use. See: https://flask-limiter.readthedocs.io#configuring-a-storage-backend for documentation about configuring the storage backend.
superset_worker       |   warnings.warn(
superset_cache        | 1:C 06 Oct 2023 10:21:38.278 # WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it can also cause failures without low memory condition, see https://github.com/jemalloc/jemalloc/issues/1328. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
superset_cache        | 1:C 06 Oct 2023 10:21:38.278 * oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
superset_cache        | 1:C 06 Oct 2023 10:21:38.278 * Redis version=7.2.1, bits=64, commit=00000000, modified=0, pid=1, just started
superset_cache        | 1:C 06 Oct 2023 10:21:38.278 # Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf
superset_cache        | 1:M 06 Oct 2023 10:21:38.279 * Increased maximum number of open files to 10032 (it was originally set to 1024).
superset_cache        | 1:M 06 Oct 2023 10:21:38.279 * monotonic clock: POSIX clock_gettime
superset_cache        | 1:M 06 Oct 2023 10:21:38.279 * Running mode=standalone, port=6379.
superset_cache        | 1:M 06 Oct 2023 10:21:38.280 * Server initialized
superset_cache        | 1:M 06 Oct 2023 10:21:38.280 * Loading RDB produced by version 7.2.1
superset_cache        | 1:M 06 Oct 2023 10:21:38.280 * RDB age 214 seconds
superset_cache        | 1:M 06 Oct 2023 10:21:38.280 * RDB memory usage when created 0.83 Mb
superset_cache        | 1:M 06 Oct 2023 10:21:38.280 * Done loading RDB, keys loaded: 0, keys expired: 0.
superset_cache        | 1:M 06 Oct 2023 10:21:38.280 * DB loaded from disk: 0.000 seconds
superset_cache        | 1:M 06 Oct 2023 10:21:38.280 * Ready to accept connections tcp
superset_init         | Skipping local overrides
superset_init         | Unknown Operation!!!
superset_init         |
superset_init         | ######################################################################
superset_init         |
superset_init         |
superset_init         | Init Step 1/4 [Starting] -- Applying DB migrations
superset_init         |
superset_init         |
superset_init         | ######################################################################
superset_init         |
superset_db           |
superset_db           | PostgreSQL Database directory appears to contain a database; Skipping initialization
superset_db           |
superset_db           | 2023-10-06 10:21:38.432 UTC [1] LOG:  starting PostgreSQL 15.4 (Debian 15.4-2.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
superset_db           | 2023-10-06 10:21:38.432 UTC [1] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
superset_db           | 2023-10-06 10:21:38.432 UTC [1] LOG:  listening on IPv6 address "::", port 5432
superset_db           | 2023-10-06 10:21:38.442 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
superset_db           | 2023-10-06 10:21:38.453 UTC [28] LOG:  database system was shut down at 2023-10-06 10:18:04 UTC
superset_db           | 2023-10-06 10:21:38.468 UTC [1] LOG:  database system is ready to accept connections
superset_init         | logging was configured successfully
superset_init         | 2023-10-06 10:21:53,193:INFO:superset.utils.logging_configurator:logging was configured successfully
superset_init         | 2023-10-06 10:21:53,239:INFO:root:Configured event logger of type <class 'superset.utils.log.DBEventLogger'>
superset_init         | /usr/local/lib/python3.9/site-packages/flask_limiter/extension.py:293: UserWarning: Using the in-memory storage for tracking rate limits as no storage was explicitly specified. This is not recommended for production use. See: https://flask-limiter.readthedocs.io#configuring-a-storage-backend for documentation about configuring the storage backend.
superset_init         |   warnings.warn(
superset_worker       | /usr/local/lib/python3.9/site-packages/celery/platforms.py:840: SecurityWarning: You're running the worker with superuser privileges: this is
superset_worker       | absolutely not recommended!
superset_worker       |
superset_worker       | Please specify a different user using the --uid option.
superset_worker       |
superset_worker       | User information: uid=0 euid=0 gid=0 egid=0
superset_worker       |
superset_worker       |   warnings.warn(SecurityWarning(ROOT_DISCOURAGED.format(
superset_worker       | Loaded your LOCAL configuration at [/app/docker/pythonpath_dev/superset_config.py]
superset_worker       |
superset_worker       |  -------------- celery@49c1ddada9e2 v5.2.2 (dawn-chorus)
superset_worker       | --- ***** -----
superset_worker       | -- ******* ---- Linux-5.15.0-1047-azure-x86_64-with-glibc2.36 2023-10-06 10:21:56
superset_worker       | - *** --- * ---
superset_worker       | - ** ---------- [config]
superset_worker       | - ** ---------- .> app:         main:0x7f6a250f7f70
superset_worker       | - ** ---------- .> transport:   redis://redis:6379/0
superset_worker       | - ** ---------- .> results:     redis://redis:6379/1
superset_worker       | - *** --- * --- .> concurrency: 2 (prefork)
superset_worker       | -- ******* ---- .> task events: OFF (enable -E to monitor tasks in this worker)
superset_worker       | --- ***** -----
superset_worker       |  -------------- [queues]
superset_worker       |                 .> celery           exchange=celery(direct) key=celery
superset_worker       |
superset_worker       |
superset_worker       | [tasks]
superset_worker       |   . cache-warmup
superset_worker       |   . cache_chart_thumbnail
superset_worker       |   . cache_dashboard_thumbnail
superset_worker       |   . fetch_url
superset_worker       |   . load_chart_data_into_cache
superset_worker       |   . load_explore_json_into_cache
superset_worker       |   . reports.execute
superset_worker       |   . reports.prune_log
superset_worker       |   . reports.scheduler
superset_worker       |   . sql_lab.get_sql_results
superset_worker       |
superset_worker_beat  | [2023-10-06 10:21:56,231: INFO/MainProcess] beat: Starting...
superset_init         | WARNI [alembic.env] SQLite Database support for metadata databases will         be removed in a future version of Superset.
superset_init         | INFO  [alembic.runtime.migration] Context impl SQLiteImpl.
superset_init         | INFO  [alembic.runtime.migration] Will assume transactional DDL.
superset_init         | ERROR [flask_migrate] Error: Can't locate revision identified by '4b85906e5b91'
superset_init         | Loaded your LOCAL configuration at [/app/docker/pythonpath_dev/superset_config.py]
superset_init exited with code 1
superset_app          | Loaded your LOCAL configuration at [/app/docker/pythonpath_dev/superset_config.py]
superset_app          | <IP_ADDRESS> - - [06/Oct/2023:10:22:10 +0000] "GET /health HTTP/1.1" 200 2 "-" "curl/7.88.1"

I'm currently using the Superset 3.0 docker image and having this same problem. Interestingly, this problem only happens when I run the image on my Linux server, but there is no problem when I run it on my Windows laptop.
Any ideas what could be the reason?
I have set TALISMAN_ENABLED and WTF_CSRF_ENABLED to False and that solved the issue for me for now, but this strikes me as a bad workaround that sacrifices security.

Running 3.0.1 on docker on Linux and having the same issue. I have set TALISMAN_ENABLED and WTF_CSRF_ENABLED to False and that hasn't solved the issue for me.

It works with edit of docker-compose-non-dev.yml to specify image version at line
x-superset-image: &superset-image apache/superset:2.1.0

Then do not forgot to rm containers and pull the image specified
@julien92git you messed things, you need to use not a Github tags and releases because you don't build images himself, but using images from Docker Hub repository.
Also, previously you updated files in container, that lost after images pull and containers recreation.

This is working for me, but the version is very old. Actually the version is 3.0.1

Could someone experiencing this issue please try adding "session_cookie_secure": False to their TALISMAN_CONFIG and seeing if that helps? From #25374 (comment).

Yea, So I ran into this issue and finally got things working with this it seems as well.  My version seems to be 3.0.1.  My config.py file is basically the defaults, with these specific additions:
TALISMAN_ENABLED = True

TALISMAN_CONFIG = {
    "content_security_policy": {
        "default-src": ["'self'"],
        "img-src": ["'self'", "data:"],
        "worker-src": ["'self'", "blob:"],
        "connect-src": [
            "'self'",
            "https://api.mapbox.com",
            "https://events.mapbox.com",
        ],
        "object-src": "'none'",
        "style-src": ["'self'", "'unsafe-inline'"],
        "script-src": ["'self'", "'strict-dynamic'"],
    },
    "content_security_policy_nonce_in": ["script-src"],
    "force_https": False,
    "session_cookie_secure": False
}```

Could someone experiencing this issue please try adding "session_cookie_secure": False to their TALISMAN_CONFIG and seeing if that helps? From #25374 (comment).

Yea, So I ran into this issue and finally got things working with this it seems as well. My version seems to be 3.0.1. My config.py file is basically the defaults, with these specific additions:
WTF_CSRF_ENABLED = False
TALISMAN_ENABLED = True

TALISMAN_CONFIG = {
    "content_security_policy": {
        "default-src": ["'self'"],
        "img-src": ["'self'", "data:"],
        "worker-src": ["'self'", "blob:"],
        "connect-src": [
            "'self'",
            "https://api.mapbox.com",
            "https://events.mapbox.com",
        ],
        "object-src": "'none'",
        "style-src": ["'self'", "'unsafe-inline'"],
        "script-src": ["'self'", "'strict-dynamic'"],
    },
    "content_security_policy_nonce_in": ["script-src"],
    "force_https": False,
    "session_cookie_secure": False
}```

I just tried this but with WTF_CSRF_ENABLED = True as well and it worked for me. (using Superset 3.0.0)
Can anyone explain the security risks (if any) associated with "session_cookie_secure": False?

Thanks @M-Salti for reporting back and the good question. I'm far from an expert and hope someone else will answer. But reading this guidance, it seems like it makes it so that the cookie will only function over HTTPS. Which I believe is why it's causing this problem: as someone is setting up Superset, they don't yet have HTTPS configured.
I feel good that it's safe to set to False until you get HTTPS configured, and appropriate for the project. As discussed in #25854 , the default of this value has always been False ... until we introduced the TALISMAN_CONFIG that implicitly has it as True by default, which caused this big headache. Setting this to False will only be restoring the value to its long-time default.

Thanks for your reply. Indeed, after I read more about it, it seems that setting this to False will allow the cookie to be sent only under HTTPS. I'm also not an expert, but this may make the app vulnerable to XSS attacks.
Nonetheless, this combination of settings is definitely much better than turning off both Talisman and CSRF.

Hi, can you try changing your TALISMAN_ENABLED config to False? If you are running of the latest docker image, you are using code from github master. It's advised to use only approved releases rather than the latest. Regardless, though, take a look at the UPDATING.md file for any breaking changes that may have occurred since the 2.1 release. The current master is moving towards 3.0 which has several breaking changes in it, and the UPDATING.md file will explain how you might need to update your system to work with the latest version.

Worked for me to switch TALISMAN_ENABLED to False

Thank you @VitalyKapustin-git this works for me,
I installed Superset in a Raspberry Pi, and I'm using my local network for access to the Superset running in a Raspberry Pi.
I set up the TALISMAN_ENABLED = False in the Superset superset_config.py file and it works for me.

I’ve got a similar setup.
Running the non-dev docker compose. I have OAuth configured with Okta. Nginix Proxy running in font of the HTTP container to perform SSL, which is functioning. Without OAuth, it works fine, with OAuth it perpetuates the 302 redirect issue. Authentication is good, user info is properly built upon return from Okta and I’m redirect to /superset/welcome/ which 302’s me back to login as seen from output.
superset_app          | <IP_ADDRESS> - - [20/Jan/2024:04:55:18 +0000] "GET / HTTP/1.0" 302 223 "-" "Mozilla/5.0 (iPad; CPU OS 17_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) EdgiOS/120.0.2210.126 Version/17.0 Mobile/15E148 Safari/604.1"

superset_app          | 2024-01-20 04:55:18,585:WARNING:root:Class 'werkzeug.local.LocalProxy' is not mapped

superset_app          | <IP_ADDRESS> - - [20/Jan/2024:04:55:18 +0000] "GET /superset/welcome/ HTTP/1.0" 302 201 "-" "Mozilla/5.0 (iPad; CPU OS 17_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) EdgiOS/120.0.2210.126 Version/17.0 Mobile/15E148 Safari/604.1"

superset_app          | <IP_ADDRESS> - - [20/Jan/2024:04:55:18 +0000] "GET /login/ HTTP/1.0" 200 48226 "-" "Mozilla/5.0 (iPad; CPU OS 17_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) EdgiOS/120.0.2210.126 Version/17.0 Mobile/15E148 Safari/604.1"

Super Docker Config:
…
from custom_sso_security_manager import CustomSsoSecurityManager

logger = logging.getLogger()

CUSTOM_SECURITY_MANAGER = CustomSsoSecurityManager # For managing User data after fetching from SSO app

# Set the authentication type to OAuth
AUTH_TYPE = AUTH_OAUTH
ENABLE_PROXY_FIX = True

# SESSION_COOKIE_SAMESITE = None
# SESSION_COOKIE_SECURE = False
# SESSION_COOKIE_HTTPONLY = False

WTF_CSRF_ENABLED = False
TALISMAN_ENABLED = True

TALISMAN_CONFIG = {
    "content_security_policy": {
        "default-src": ["'self'"],
        "img-src": ["'self'", "data:"],
        "worker-src": ["'self'", "blob:"],
        "connect-src": [
            "'self'",
            "https://api.mapbox.com",
            "https://events.mapbox.com",
        ],
        "object-src": "'none'",
        "style-src": ["'self'", "'unsafe-inline'"],
        "script-src": ["'self'", "'strict-dynamic'"],
    },
    "content_security_policy_nonce_in": ["script-src"],
    "force_https": False,
    "session_cookie_secure": False
}
…

Nginix Config:
server {
    listen 443 ssl;
    server_name superset.<domain_name>.com;

    ssl_certificate /etc/letsencrypt/live/superset.<doamin_name>.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/superset.<domain_name>.com/privkey.pem;

    proxy_buffer_size 128k;
    proxy_buffers 4 256k;
    proxy_busy_buffers_size 256k;

    location / {
        proxy_pass http://localhost:8088;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

I’ve tried every combination of recommend “fixes” in this thread. I’m sure it has to do with the cookies, but I’m not sure where to go from here. Any thoughts are greatly appreciated.

I set up the TALISMAN_ENABLED = False page login loop ,if i set up the TALISMAN_ENABLED = True ,i can't embedded dashboard in App. How to fix it?
Thanks!

TALISMAN_ENABLED = True # Enable CSP
TALISMAN_CONFIG = {
    "content_security_policy": {
        "base-uri": ["'self'"],
        "frame-ancestors": ["'self'", "*"],
        "default-src": ["'self'"],
        "img-src": [
            "'self'",
            "blob:",
            "data:",
            "https://apachesuperset.gateway.scarf.sh",
            "https://static.scarf.sh/",
        ],
        "worker-src": ["'self'", "blob:"],
        "connect-src": [
            "'self'",
            "https://api.mapbox.com",
            "https://events.mapbox.com",
        ],
        "object-src": "'none'",
        "style-src": [
            "'self'",
            "'unsafe-inline'",
        ],
        "script-src": ["'self'", "'strict-dynamic'"],
    },
    "content_security_policy_nonce_in": ["script-src"],
    "force_https": False,
    "session_cookie_secure": False,
}

None of these suggestions are working for me...
The closest I can get is the login page embedded, but clicking login after specifying the credentials just redirects back to the login. And I get and ERR_BLOCKED_BY_CLIENT error trying to reach this URL: https://apachesuperset.gateway.scarf.sh/pixel/0d3461e1-abb1-4691-a0aa-5ed50de66af0/0.0.0-dev/null/null
No idea what the null/null at the end is supposed to be or how to fix it. I've tried all of the above suggestions, using a variety of versions from 2.1 to 3.1.1, trying both normal docker compose and non-dev, etc.

I'm running HTTP and this works for me:
ENABLE_PROXY_FIX = False
WTF_CSRF_ENABLED = False
TALISMAN_ENABLED = False

We haven't found any Content Security Policy (CSP) defined in the configurations. Please make sure to configure CSP using the TALISMAN_ENABLED and TALISMAN_CONFIG keys or any other external software. Failing to configure CSP have serious security implications. Check https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP for more information. You can disable this warning using the CONTENT_SECURITY_POLICY_WARNING key.
2024-08-02 13:12:39,025:WARNING:superset.initialization:We haven't found any Content Security Policy (CSP) defined in the configurations. Please make sure to configure CSP using the TALISMAN_ENABLED and TALISMAN_CONFIG keys or any other external software. Failing to configure CSP have serious security implications. Check https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP for more information. You can disable this warning using the CONTENT_SECURITY_POLICY_WARNING key.

Have anybody integrated superset within java spring boot application?

Has anybody integrated superset within java spring boot application?

I'd encourage you to join slack and/or GitHub Discussions to find some folks that have.


docs(guide/Forms): describe your change...

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Typo bug fix
What is the current behavior? (You can also link to an open issue here)
The last example does not function due to mis-capitalization of directive name and element attribute
What is the new behavior (if this is a feature change)?
Fix broken example
Does this PR introduce a breaking change?
Don't think so
Please check if the PR fulfills these requirements

[ ] The commit message follows our guidelines: https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit-message-format
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

Other information:
Typos in contentEditable directive example

Thx for the PR, but I'm afraid we'll have to pass this time. The changes will actually break the example (see inline comments).
Thx for taking the time anyway. Looking forward to your next PR :stuck_out_tongue:


Added ability to write to stream  as PNG

Added functionality for writing WordCloud image data to an input stream. This makes the library even more convenient to use in on-line applications

:+1: I will look into making a generic Writable interface (or something similar) for supporting more output types in the future :)


Be able to specify timeout

It takes a very long time before a connection attempt times out. Right now there's no way to configure a connect timeout in the AMQPClient constructor or the .connect() function, which would be great to have.
For now, I wrote the following workaround:
    const connectionPromise = amqp.connect();
    amqp.socket?.setTimeout(5000);
    connection = await new Promise((resolve, reject) => {
      amqp.socket?.on('timeout', () => {
        amqp.socket?.destroy();
        reject(new DestinationError('Timeout hit'));
      });
      connectionPromise.then(resolve).catch(reject);
    });

Pretty sure https://github.com/cloudamqp/amqp-client.js/pull/78 improved on this, are you able to check @everhardt? Using the heartbeat parameter you can control the timeout


Sync sledgehammer with what we ship for sleshammer

LGTM

As this is just a sync, and we do not use the bits from here, I'll just merge. We should consider using this as our source for the package, though...


Delete and autoincrement issue

I was trying to implement AnimatedList with elements taken from Moor database, where element id was autoincrementing. So when I delete an element I have to delete it from AnimatedList and provide an element index in the list. I was sure that it has to be identical with id in the
database, but it actually isn't.
After deletion instead of change ids of all elements in table, it just does nothing, so it causes unwanted consequences

After deletion instead of change ids of all elements in table, it just does nothing, so it causes unwanted consequences

In sqlite, the auto-increment doesn't reset after deleting rows, this is by design. So if you insert 5 rows, delete them, and then insert another one, the only row should have an id of 6. You can read more on autoincrement in the sqlite documentation.

I was sure that it has to be identical with id in the database, but it actually isn't.

The auto-increment id not counting down can be a bit counterintuitive, but as you've found out it's not suitable as an item index for a list. There are Flutter packages which can turn a Stream<List<T>> into an AnimatedList by automatically calculating the difference whenever the stream updates. A quick search on pub yields the animated_stream_list or the implicitly_animated_list packages which might achieve what you need.
I'm closing this as it looks like moor is working as intended, but if you have any questions please feel free to reply.

It is possible to reset the auto increment with the following custom query:
await database.customStatement("DELETE FROM SQLITE_SEQUENCE WHERE NAME='knowledge_summary'");


Add WhiteSource CVEs scan to Github workflow

Description
Refer to #1157, WhiteSource integration may not work correctly at this time. They have an issue on their side. We are switching to our Plan B using Github Actions for automating WhiteSource scan using old script from ODFE. This workflow will update the scan results in our testing product on WhiteSource dashboard first so that it won't overwrite the previous manual scan results that team tracked.
Issues Resolved
Backup plan for #1157
Check List

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Is there an example of this workflow that I could see? I'm not sure that this has executed on your fork

This is using secret that stored in build repo. I can't run it on my fork. We had same workflow before here. https://github.com/opensearch-project/opensearch-build/blob/41064bc5d3cebed31d06eab2c88d12462e141569/.github/workflows/check-vulnerability-whitesource.yml

Is there an example of this workflow that I could see? I'm not sure that this has executed on your fork

This is using secret that stored in build repo. I can't run it on my fork. We had same workflow before here. https://github.com/opensearch-project/opensearch-build/blob/41064bc5d3cebed31d06eab2c88d12462e141569/.github/workflows/check-vulnerability-whitesource.yml

That change was executed months ago, lets re-run everything with the latest and greatest to make sure everything is still working well.

Regardless of Jenkins vs. GhA, shouldn't this live in the OpenSearch repo?

We are closing this one since this approach won't work now.


iterator returns a continuous loop

The iterator that returns search results is neverending. It just keeps looping through the same set of files continuously.

I see the issue.  The package on pypi doesn't have the fix that was created for this that sets the new page token inside the loop on the Media class search function.

Indeed. I updated the pypi package, now it is in sync with the current.

I see the issue. The package on pypi doesn't have the fix that was created for this that sets the new page token inside the loop on the Media class search function.

thank you for the catch. I couldn't reproduce it :-)


[SPARK-21890]

What changes were proposed in this pull request?
https://issues.apache.org/jira/browse/SPARK-21890
Modified to pass creds to get delegation tokens
How was this patch tested?
Manual testing on our secure cluster

Can one of the admins verify this patch?

Mind fixing the title to be, [SPARK-xxxx][COMPONENT] Title, and filling the PR description up to describe how this fixes the issue?

ok to test

Test build #81317 has started for PR 19103 at commit 7043d98.

@redsanket please submit a pr against master as well.  I doubt the master would cherry pick back since all that has changed so you can leave this one open as well.

I think the tmpCreds here was just a optimization so we didn't have to look at all the creds for the renewer so I think this is fine. @jerryshao  you don't remember anything else where it explicitly required not passing the old creds?

Test build #81317 has finished for PR 19103 at commit 7043d98.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/81317/
Test PASSed.

cc @vanzin @mgummelt

This needs to be opened against master first.

Oozie client gets the necessary tokens the application needs before launching. It passes those tokens along to the oozie launcher job (MR job) which will then actually call the Spark client to launch the spark app and pass the tokens along.

The oozie launcher job cannot get anymore tokens because all it has is tokens ( you can't get tokens with tokens, you need tgt or keytab).

The error here is because the launcher job runs the Spark Client to submit the spark job but the spark client doesn't see that it already has the hdfs tokens so it tries to get more, which ends with the exception.

So the problem is that Oozie will get tokens for Spark instead of letting Spark do itself, and in Oozie launcher we should not let Spark Yarn#client to get tokens itself since there might not have tgt available in Oozie launcher.
From my understanding of your issue, this seems like a more general issue regarding Oozie launcher and Spark token manage stuff. With the patch, looks like it only address the HDFS issue, how do we handle hive/hbase, looks like still have issues.

In general it feels like this code shouldn't even be running if the current user doesn't have a TGT to start with.
But this patch restores the behavior from Spark 2.1, so if the PR is opened against master it should be ok to merge.

@tgravescs , I think it is in AMCredentialRenewer we explicitly create a new Credential every time when issuing new tokens.
    // HACK:
    // HDFS will not issue new delegation tokens, if the Credentials object
    // passed in already has tokens for that FS even if the tokens are expired (it really only
    // checks if there are tokens for the service, and not if they are valid). So the only real
    // way to get new tokens is to make sure a different Credentials object is used each time to
    // get new tokens and then the new tokens are copied over the current user's Credentials.
    // So:
    // - we login as a different user and get the UGI
    // - use that UGI to get the tokens (see doAs block below)
    // - copy the tokens over to the current user's credentials (this will overwrite the tokens
    // in the current user's Credentials object for this FS).

That's when using principal / keytab and generating new tokens; it's separate from the code path being changed here. The initial tokens are obtained in Client.scala with the current user's credentials.

@vanzin From my understanding seems like it is a workaround to avoid issuing new HDFS tokens (since this user credential we already has HDFS tokens). But how to handle HBase/Hive thing without TGT?

I don't know; perhaps they'll fail, which is why I think the correct behavior would be to skip this credential manager code altogether if a TGT doesn't exist.
But that would at least be the same behavior as Spark 2.1, while the behavior in the HDFS provider has definitely changed.

hive and hbase token fetch can be turned off (ie spark.yarn.security.tokens.hive.enabled=false).  I thought they didn't work the same as hdfs core as far as not getting one if you have, but would need to check.  You tell oozie to get those before launching via the oozie credentials configurations.

BTW Oozie can also disable the HDFS provider (spark.yarn.security.credentials.hadoopfs.enabled=false, I think). But it would be nice if Spark was able to do that by itself is the current UGI does not have a TGT (or, alternatively, some way to disable all of the credential providers with a single setting). But that's for a separate PR.
This one looks ok but it really needs to be opened against master instead.

yes user stated he will be opening one for master, but that is quite a bit different due to the credentials stuff moving around so I think this one will have to stay open anyway.  But I agree we should definitely look at the master one first.

@vanzin @tgravescs sorry for the delay, will put up a PR against master, we can move further discussion there, about the suggested improvements, I put up a PR against master just for workaround. https://github.com/apache/spark/pull/19140

Jenkins,test this please

Test build #81522 has started for PR 19103 at commit 7043d98.

Test build #81522 has finished for PR 19103 at commit 7043d98.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/81522/
Test PASSed.

Looks good (since the master PR didn't merge). Merging to 2.2. @redsanket please close the PR manually.


source_id -- edits to 'ACCESS-CM2’

institution_id = CSIRO-ARCCSS
release_year = 2019
activity_participation = [CMIP FAFMIP OMIP RFMIP ScenarioMIP SIMIP]
land:
description = CABLE2.5
seaIce:
description = CICE5.1.2

@sjmarsland thanks for the update, your changes are now in place, take a peek at CMIP6_source_id.html and let me know of any further tweaks required


feedback

Hi,
Thanks for the user guide, really helpful :-).
Before step no.7,  it is required to have populated your new key vault
with at least one key (key1 in the YAML) and one secret (secret1).
It would help also to show the command required to retrieve the USER_ASSIGNED_CLIENT_ID value
az aks show --resource-group
--name
--query addonProfiles.azureKeyvaultSecretsProvider.identity.clientId
--output tsv
the clientId should not be confused with ObjectId referred previously.
Hopes this helps,
Best Regards
Ronan

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: ec9ff712-aa4c-4e95-ba96-2405010d9f83
Version Independent ID: f553a5a4-a20f-8efd-3712-e64112c35676
Content: Access Azure Key Vault with the CSI Driver Identity Provider - Azure Kubernetes Service
Content Source: articles/aks/csi-secrets-store-identity-access.md
Service: azure-kubernetes-service
GitHub Login: @Nickomang
Microsoft Alias: nickoman

@ronan-martorell
Thanks for your feedback! We will investigate and update as appropriate.

@ronan-martorell
Thanks for bringing this to our attention.
I'm going to assign this to the document author so they can take a look at it accordingly.

@ronan-martorell, thanks for the feedback. I've updated the article based on your suggestions.


Add support to KUBECONFIG env var

kubectl supports a KUBECONFIG env var that allows us to use other kubeconfig file instead of default $HOME/.kube/config
It would be good to support it as well

Thanks @fandujar I started playing around with mizu few mins back. I don't have permission on ALL resources on the cluster but I am limited to a specific namespace. I was wondering what permission would it need to run mizu ?
I see below error even when I specify the namespace using -n option
$ ./mizu tap "shopping-cart-*" -A -n ksudhir007
Tapping pods in all namespaces
warning: could not ensure mizu rbac resources exist serviceaccounts "mizu-service-account" is forbidden: User "ksudhir007" cannot get resource "serviceaccounts" in API group "" in the namespace "default"
Error creating mizu tapper daemonset: daemonsets.apps "mizu-tapper-daemon-set" is forbidden: User "ksudhir007" cannot patch resource "daemonsets" in API group "apps" in the namespace "default"

Removing mizu resources
Error removing DaemonSet mizu-tapper-daemon-set in namespace default: daemonsets.apps "mizu-tapper-daemon-set" is forbidden: User "ksudhir007" cannot list resource "daemonsets" in API group "apps" in the namespace "default" (daemonsets.apps "mizu-tapper-daemon-set" is forbidden: User "ksudhir007" cannot list resource "daemonsets" in API group "apps" in the namespace "default",daemonsets.apps "mizu-tapper-daemon-set" is forbidden: User "ksudhir007" cannot list resource "daemonsets" in API group "apps" in the namespace "default")

Happy to update the documentation once I find the answer.

https://github.com/up9inc/mizu/pull/114

Thanks @fandujar I started playing around with mizu few mins back. I don't have permission on ALL resources on the cluster but I am limited to a specific namespace. I was wondering what permission would it need to run mizu ?
I see below error even when I specify the namespace using -n option
$ ./mizu tap "shopping-cart-*" -A -n ksudhir007
Tapping pods in all namespaces
warning: could not ensure mizu rbac resources exist serviceaccounts "mizu-service-account" is forbidden: User "ksudhir007" cannot get resource "serviceaccounts" in API group "" in the namespace "default"
Error creating mizu tapper daemonset: daemonsets.apps "mizu-tapper-daemon-set" is forbidden: User "ksudhir007" cannot patch resource "daemonsets" in API group "apps" in the namespace "default"

Removing mizu resources
Error removing DaemonSet mizu-tapper-daemon-set in namespace default: daemonsets.apps "mizu-tapper-daemon-set" is forbidden: User "ksudhir007" cannot list resource "daemonsets" in API group "apps" in the namespace "default" (daemonsets.apps "mizu-tapper-daemon-set" is forbidden: User "ksudhir007" cannot list resource "daemonsets" in API group "apps" in the namespace "default",daemonsets.apps "mizu-tapper-daemon-set" is forbidden: User "ksudhir007" cannot list resource "daemonsets" in API group "apps" in the namespace "default")

Happy to update the documentation once I find the answer.

The minimum permissions needed are (currently for the default namespace, will be configurable later on):
- apiGroups:
  - ""
  - apps
  resources:
  - pods
  - services
  verbs:
  - list
  - get
  - create
  - delete
- apiGroups:
  - ""
  - apps
  resources:
  - daemonsets
  verbs:
  - list
  - get
  - create
  - patch
  - delete

You won't be able to run mizu at all without these resources.
For traffic ip to k8s service name resolving to work you'll need these optional permissions:
- apiGroups:
  - ""
  - apps
  - "rbac.authorization.k8s.io"
  resources:
  - clusterroles
  - clusterrolebindings
  - serviceaccounts
  verbs:
  - get
  - create
  - delete

This will allow mizu to create the necessary rbac resources that give mizu permissions to watch the cluster's pods, services and endpoints in order to resolve traffic ips.

Thanks @RamiBerm - this issue can be closed - both pull requests are merged.


publishing new app: shipweatherclock

adding an app that displays:
1. Text of
- current time
- low and high temperatures for the day
- current temperature
2. Ship on the ocean scene with:
- wave animations based on windspeed
- sun and moon that rise/fall based on time to sunrise/sunset
- sky colors that change based on day/night/sunrise/sunset
- clouds and precipitation based on current weather

I have read the CLA Document and I hereby sign the CLA


[BUG] Webcord needs to be closed from tray in order to initiate shutdown in macOS Monterey

Aknowledgements

[X] I have checked that there's no other issue describing the same or
similar problem that I currently have, regardless if it has been
closed or open.

[X] I can confirm that this is not an issue with the Discord website,
but it is a problem specific to the WebCord itself.

[ ] I have tried running the build from the master branch and it does
not have any fixes implemented according to my issue.

[ ] My issue describes one of the unstable and/or not fully implemented
features.

[X] I have found a workaround to mitigate or temporarily fix this issue
(please write it in Additional context section).

Operating System / Platform
🍎 MacOS
Operating system architecture
x64 (64-bit Intel/AMD)
Electron version
I am unable to find any "About panel" menu in Webcord
Application version
v3.3.0
Bug description
macOS cannot shut down properly when Webcord is launched, the workaround for this is to close it manually from the tray icon, or to Force Stop it. I don't think it's related, but both my AMD and my Intel machines are hackintoshes.
Additional context
No response

I am unable to find any "About panel" menu in Webcord

It's About section in the tray.

macOS cannot shut down properly when Webcord is launched, the workaround for this is to close it manually from the tray icon, or to Force Stop it

Isn't macOS actually supposed to manage this and close the app when it does not declare to block the shutdown process? I don't think Electron does block shutdown in WebCord, as it does not use the powerMonitor to prevent the shutdown event.

I don't think it's related, but both my AMD and my Intel machines are hackintoshes.

Probably someone with genuine Apple device would need to reproduce this issue.

Hi, other Electron apps like normal Discord and Visual Studio Code don't have this problem, so it's a Discord problem. And I don't think it's hackintosh related as everything else works perfectly.

Hi, other Electron apps like normal Discord and Visual Studio Code don't have this problem, so it's a Webcord problem. And I don't think it's hackintosh related as everything else works perfectly.

Hmm, then I'll take a look at code. It could be that the close button prevention actually affects the shutdown as well, but if that would be a case, disabling tray should fix the issue... Could you confirm this?

What do you mean by disabling tray? Also, if I understood your question correctly, it doesn't even close when I right click > exit like any other app, I have to do it from tray icon, which by the way is way oversized.

What do you mean by disabling tray?

Simply, go to File → Settings at the menu bar and disable the tray functionality.

Also, if I understood your question correctly, it doesn't even close when I right click > exit like any other app, I have to do it from tray icon, which by the way is way oversized.

That is because it uses the same logic for closing windows across all platforms. If Right Mouse Click + Exit emmits the close event in Electron (which would be the same for the close button), it will be prevented and hidden instead. Only the tray has the priviledge to bypass this mechanism. You can however disable it on demand if you wish to, however the changes will appear after the app restart.

Hi, there is no File button either in the menu bar or in the app itself.

Hi, there is no File button either in the menu bar or in the app itself.

This is how it looks like on Linux, on XFWM window manager:

It is visible by the default and works on all platforms, but you could hide it in the settings. You can press the ALT key to show it in that case.

Hi, other Electron apps like normal Discord and Visual Studio Code don't have this problem, so it's a Webcord problem.

This logic actually might be wrong; are you sure both Discord and VSCode uses the exact same version of the Electron? And as of Discord, they even use their own Electron binary – are you sure it doesn't contain any fix even if it is at the same Electron version?
Sometimes, at rare situations, either Electron or Chromium developers announces the new bug even at patch release, which shouldn't be breaking. This is why it is so hard to know whenever my code is OK or it is broken because of the Electron. And the tray logic that prevents the window from being closed is quite old as well, probably hasn't been much changed since Electron Discord Webapp times and 0.x.y major release (I think it exists since tray actually was implemented in WebCord, which probably was in initial commit/release).

Also, Support.md in docs/ states that macOS is the worst platform supported by WebCord. This is because Apple doesn't like to use their software on any other hardware than their own so much that I believe they don't provide any development images that would be easy to install and provide the actual environment to test how the software runs. Even Windows policy allows using it for the development for free, and I believe Microsoft does even provide the special Windows builds to test the software with. Nothing like that was heard in case of the macOS.

macOS has the menu bar at the top, not under the Window Title, and for Webcord there is no File menu. Pressing Option (ALT) does nothing.

Found another problem. When letting the application run in the background and re-starting it I get this error.

This one is actual WebCord problem: there's no event cleanup, as I never expected to run process in the background without the actual windows. And the question is this: should I really let app run in the background, or is it better to just close it on macOS? What macOS expects and handles the best and why?
It might be actually quite time-consuming due to current's WebCord code architecture – adding a code to remove every possible listener or handler would actually take some time. And it does not improve anything at all, most of code depends on window and needs to be killed anyway once window is closed.

As of the original bug, it might be fixed in a0522b0. I might provide debug builds there (ZIP-ed, might need to be fixed with xattr), so you will be able to test it. As of the 2nd bug, I've mitigated it by letting app to kill the process once there's no more windows opened, so it behaves identically to Linux and Windows platforms. I may improve it to work like Electron developers recommend, but I'm still thinking if it is worth it – unless it will bring more integration to the macOS or be more intuitive, I'll keep it this way, so feel free to share your opinion on that.

Thanks. I will build the latest version as soon as I can. I don't need xattr as I disabled gatekeeper.

With the latest version Webcord cannot be closed AT ALL, even from tray icon, I had to force shutdown my system.

After disabling tray though, the whole program closes when pressing the close button, not just the window.

This is expected behaviour, although I don't know if this is how macOS software should behave. See my previous comment:

As of the 2nd bug, I've mitigated it by letting app to kill the process once there's no more windows opened, so it behaves identically to Linux and Windows platforms.

With the latest version Webcord cannot be closed AT ALL, even from tray icon, I had to force shutdown my system.

Whoops, I've noticed that will-quit event does not executes before window is being closed, but before-quit does behave exactly how I needded. So 1becfce should fix this.

This is expected behaviour, although I don't know if this is how macOS software should behave. See my previous comment:
It is not.

Whoops, I've noticed that will-quit event does not executes before window is being closed, but before-quit does behave exactly how I needded. So 1becfce should fix this.

When tray mode is enabled (default), it closes as excepted, but there is still one problem, when I close the window of the app it will be "locked" until I press the tray icon. After that, it will appear again.

It is not.

I'll probably work on that later. I'm also still unsure how it really should behave and what people would expect from  – should I kill everything running in the background, but keep Electron itself still running? Or some parts of the code like WebSocket Server or update  checker should stay running, but be prepared for main window being closed when it is running?

When tray mode is enabled (default), it closes as excepted, but there is still one problem, when I close the window of the app it will be "locked" until I press the tray icon. After that, it will appear again.

I guess by term locked, you mean that you can't reactivate the app using dock? I'm unsure if I should show window on activate event. But I think that's another issue, not to discuss about the current one.

And since I don't own macs and using Hackintosh (e.g. to setup a VM) are in legal grey area, I may not work on the better integration of WebCord within the macOS system. If you want to, you can still open a feature request, since mac support is quite limited and some mac specific behaviour / features might not be implemented in WebCord. It will be however likely flagged as wontfix.
I believe this issue (i.e. proper shutdown in macOS) has been fixed and further issues should be opened to document the integration within the macOS dock.

I'll probably work on that later. I'm also still unsure how it really should behave and what people would expect from – should I kill everything running in the background, but keep Electron itself still running? Or some parts of the code like WebSocket Server or update checker should stay running, but be prepared for main window being closed when it is running?

No idea about the under the hood stuff, you could look at other applications like Visual Studio Code which work fine.

I guess by term locked, you mean that you can't reactivate the app using dock?

Yes.

using Hackintosh (e.g. to setup a VM) are in legal grey area

It's not illegal to use a hackintosh. Against a company ToS' doesn't mean illegal.

If you want to, you can still open a feature request

Why would there be another issue that has the same base problem? I see no point in not continuing here.

It's not illegal to use a Hackintosh. Against a company's ToS doesn't mean illegal.

I didn't say it is illegal for that reason. But I think there's a lot of concerns about the legality of that in which legal grey area is accurate term to describe that. But that's discussion outside of this issue. I just say I may not setup a VM for testing macs.

Why would there be another issue that has the same base problem? I see no point in not continuing here.

Mostly, because it would make it impossible to watch for the state of separate issue within the macOS. And this issue has different cause than the others you've described, as it used a bad assumption app.quit would not be used internally by the Electron to close the app. The other issues however are caused due to WebCord's code structure, which expects that with the lack of the window, there won't be any reason to process to continue in the background. And for most of platforms this is OK, but macOS' dock logic is an exception, when (IDK why) it expects for a process to continue. The lack of experience with macOS makes it hard for me to progress on that, since I'm unsure how different parts of the app should behave when window is closed and how killing the process actually works in macOS.
And, to be honest, fixing app.quit has fixed another issues as well. For instance, CTRL+C (or SIGINT signal) kills the app on Linux as it should (previously, this signal would need to be emitted twice, now it works immediately).

No idea about the under the hood stuff, you could look at other applications like Visual Studio Code which work fine.

VSCode structure is different from WebCord's, not only it does not support the tray and is developed to be a desktop app in mind, but also it usually does not start any server and if it does, they're strictly dependant on the current window. In WebCord, some background tasks are independent from the UI and could be ran even with all windows closed.


Update entities

Removed commented out code and out-of-date comments.
Business.cs's constructor didn't instantiate Address. This is fixed.
Booking.cs, Service.cs, and ServiceAvailability.cs used an in to store appointment length. This was changed to use TimeSpan. Constructors updated.

Updated DBContext.cs to reflect change in Booking object construction.

Undid change to Business.cs. Update database migration.


[Fix] for Issue #557 moving focus to the keyboard shortcuts panel when opened

Modified aria attributes and focusing behavior so that the keyboard shortcuts panel receives focus, is read appropriately by screen readers, prevents focus from accidentally moving back to the other elements without use of the proper shortcuts, and then returns focus to the appropriate place when closed.
I tested this on Chrome and Safari with Mac VoiceOver and FireFox with no screen reader.  It seems that all the keyboard navigation and screen reading is working consistently across them all now.  Triggering the keyboard shortcuts panel opens, focuses and returns focus when closed appropriately now regardless of how its triggered.
EDIT: also tested in Microsoft Edge along with NVDA.

Coverage increased (+0.4%) to 87.148% when pulling 33b133fd3d4b026d260d71817ff125aeaa53367f on fix_issue557_keyboard_shortcuts_panel into ae49b715db1c064e833379aded85eff81cd866fa on master.

Coverage increased (+0.4%) to 87.165% when pulling 8396f889afd5122b80a5ec3cbab41e79fbd13dea on fix_issue557_keyboard_shortcuts_panel into ae49b715db1c064e833379aded85eff81cd866fa on master.

Coverage increased (+0.4%) to 87.165% when pulling b43aaf85d1e523d243bb186fa622ac7301fcde42 on fix_issue557_keyboard_shortcuts_panel into ae49b715db1c064e833379aded85eff81cd866fa on master.

I just want to follow up on this and make sure there weren't any more outstanding actions on my part that you may be waiting for.  I think I got it all but if not let me know!

Coverage increased (+0.4%) to 87.192% when pulling 023c50c169e549ddf08d62a7410bb94a2265c5f5 on fix_issue557_keyboard_shortcuts_panel into 7eb21918799a9fbec7be615fed9d447e4c4f7c84 on master.

Coverage increased (+0.4%) to 87.192% when pulling c742e761cc2d59c1503a37edaf49aecff32a99c9 on fix_issue557_keyboard_shortcuts_panel into 44fa104e44f992dd218d8ed4fb213544b9498af8 on master.

Looking in to build failures now, all I did was rebase on master to pick up any recent changes and then add comments...

Linting error:
111:1  error  Line 111 exceeds the maximum line length of 100  max-len
:woman_facepalming:

Coverage increased (+0.4%) to 87.192% when pulling 121c2e026c98f07b66f5ee0a78737615841689ee on fix_issue557_keyboard_shortcuts_panel into 44fa104e44f992dd218d8ed4fb213544b9498af8 on master.

Coverage increased (+0.4%) to 87.192% when pulling b3d3de1f49a38bfc436a0ff6a427a411e44e4427 on fix_issue557_keyboard_shortcuts_panel into 44fa104e44f992dd218d8ed4fb213544b9498af8 on master.

Yay!  🎉 😌

Would it be cool to go ahead and push a version update now that this is in?  Patch?  I can do it if y'all are busy but didn't want to assume in case you were holding off for something on its way.

v15.1.0 is out!


Scrolling effect on sidebar

Description
The sidebar was no scrolling on clicking the the required button
Related issue(s)
Issue#1582

Also follow the conventional commits specifications ->
fix : scrolling effect on sidebar

@anj20 I'm closing this PR as I got #1668 more accurate than this one to resolve the issue. Thanks for devoting time to resolving this issue. Kindly look into other issues too


"Error: Module did not self-register" with Node v12 worker threads

I'm finding that node-sass is failing to load when I'm using mocha-parallel-tests. It turns out that mocha-parallel-tests uses worker threads in Node v12, and that seems to be the reason. The first thread to require("node-sass") succeeds, but the second one fails with Error: Module did not self-register.
It seems reasonable that someone might want to use node-sass in worker threads, e.g. something similar to thread-loader. In my case, I'm running integration tests (in parallel) where some SCSS compilation is part of the thing being tested.
Similar error messages have been reported before, but they precede the introduction of worker threads so I presume they are caused to something else.
Minimal reproduction:
const { Worker } = require("worker_threads");

function render(element) {
    return new Promise((resolve, reject) => {
        const worker = new Worker(`
            const sass = require("node-sass");
            const data = "${element} { font-weight: bold }";
            const css = sass.renderSync({ data }).css.toString("utf8");
            console.log(css);
        `, { eval: true });
        worker.on("error", reject);
        worker.on("exit", exitCode => {
            if (exitCode > 0)
                reject(new Error(`Worker exited with code ${exitCode}`));
            resolve();
        })
    });
}

// Spawn the workers in sequence, not in parallel, to make it easier to debug
async function bug() {
    await render("b");
    await render("strong");
}

bug().catch(err => console.error(err));

Output:
lee@lee-desktop:~/Work/restapi$ node sassbug.js
b {
  font-weight: bold; }

internal/modules/cjs/loader.js:977
  return process.dlopen(module, path.toNamespacedPath(filename));
                 ^

Error: Module did not self-register.
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:977:18)
    at Module.load (internal/modules/cjs/loader.js:790:32)
    at Function.Module._load (internal/modules/cjs/loader.js:703:12)
    at Module.require (internal/modules/cjs/loader.js:830:19)
    at require (internal/modules/cjs/helpers.js:68:18)
    at module.exports (/home/lee/Work/restapi/node_modules/node-sass/lib/binding.js:19:10)
    at Object.<anonymous> (/home/lee/Work/restapi/node_modules/node-sass/lib/index.js:14:35)
    at Module._compile (internal/modules/cjs/loader.js:936:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:947:10)
    at Module.load (internal/modules/cjs/loader.js:790:32)

Versions

NPM version (npm -v): 6.11.2
Node version (node -v): v12.10.0
Node Process (node -p process.versions):

  node: '12.10.0',
  v8: '7.6.303.29-node.16',
  uv: '1.31.0',
  zlib: '1.2.11',
  brotli: '1.0.7',
  ares: '1.15.0',
  modules: '72',
  nghttp2: '1.39.2',
  napi: '4',
  llhttp: '1.1.4',
  http_parser: '2.8.0',
  openssl: '1.1.1c',
  cldr: '35.1',
  icu: '64.2',
  tz: '2019a',
  unicode: '12.1'
}

Node Platform (node -p process.platform): linux
Node architecture (node -p process.arch): x64
node-sass version (node -p "require('node-sass').info"):

node-sass       4.12.0  (Wrapper)       [JavaScript]
libsass         3.5.4   (Sass Compiler) [C/C++]

npm node-sass versions (npm ls node-sass): └──<EMAIL_ADDRESS>

Binding:
I installed the binding using standard npm install, but I also tried https://github.com/sass/node-sass/releases/download/v4.12.0/linux-x64-72_binding.node (they have the same SHA256 hash anyway)

I tried switching NODE_MODULE for NAN_MODULE_WORKER_ENABLED - it compiles, works, and only segfaults 10% of the time! OK, maybe 25%. I'm counting that as a success anyway :shipit:
lee@lee-desktop:~/Work/restapi$ node sassbug.js
b {
  font-weight: bold; }

Segmentation fault (core dumped)

I sort of expected this to work given that node-sass doesn't have any global state that I can see. Maybe libsass is doing something not thread-safe, but I wouldn't know about that.

We currently do not support workers - our add on is not context-aware.
We are using libuv lowlevel routines and it might be difficult to make it worker-aware. Can you try to produce a backtrace from your crash?

Hi, I will give this a try! I did build node-sass with debugging on and didn't get much useful, but I'll try some more when I get a chance.
It didn't seem like node-sass used much global state, so I naïvely assumed it might be okay - I assumed global state was the main issue with context awareness, but it's been a long time since I wrote any node native modules and it's changed a lot!

We have some static initialization that is done by C++ runtime for us.
An example of a problem that was caused by static initialization was this https://github.com/sass/node-sass/issues/1283#issuecomment-169845062
However we run libsass code in a background thread (outside of the main JavaScript loop) so maybe there is something we can investigate.


Thank you for writing this book. I have a question.

I am looking to follow along with your book. Would you mind explaining to me why is it necessary to install the tool chain ? The program we are writing is able to execute a riscv compliant asm file, right ?

Thank you for your question!
The reason to install the toolchain is not to use the compressed instructions (RV64C) when we compile C code and xv6 code in the future. The default toolchain for RISC-V in my environment uses the compressed instructions that we'll not implement. The default setting for the toolchain might be different depending on the environment and I just make sure that we have the same setting for the toolchain.


A* AI Algorithmns

Unity 2D doesn't have any inbuilt pathfinding within the game engine. A* provides 2d algorithms to provide object avoidance while following the player. All Unity tutorials I found were based on this library. Before using it I want to get approval before using a 3rd party library and find out what licensing it requires.

It appears that there licensing allows for use in commercial projects. This includes the free version. For this reason I believe that it is ok for us to use it as everyone in the competition will have equal access to it.

Can you post the link?

They have this in their FAQ. Currently trying to track down the exact use license.

I might have found a way to get Unity NavMeshes to work in 2D

They follow the Unity asset store public use license so we should be good to use it.

Ok, cool the way to use unity natively didn't work.

Also found this on the README.MD stating The license is the AssetStore Free License and the AssetStore Commercial License respectively for the Free and Pro versions of the project.


[Windows] flutter pub get failed (66; , errno = 1314))

When i running flutter pub get in my app, my computer console print
Cannot create link, path = 'C:\Users\linjianchou\AppData\Local\Pub\Cache\_temp\dirc2beee1f\macos\Classes\FlutterBluePlugin.h' (OS Error: Client does not have required privileges. errno = 1314)
Running "flutter pub get" in ismp_app...
pub get failed (66; , errno = 1314))

flutter doctor
Flutter assets will be downloaded from https://storage.flutter-io.cn. Make sure you trust this source!
[√] Flutter (Channel stable, 2.10.4, on Microsoft Windows [Version 10.0.19042.985], locale zh-CN)
    • Flutter version 2.10.4 at D:\src\flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision c860cba910 (13 days ago), 2022-03-25 00:23:12 -0500
    • Engine revision 57d3bac3dd
    • Dart version 2.16.2
    • DevTools version 2.9.2
    • Pub download mirror https://pub.flutter-io.cn
    • Flutter download mirror https://storage.flutter-io.cn

[√] Android toolchain - develop for Android devices (Android SDK version 32.1.0-rc1)
    • Android SDK at D:\Android\AndroidSdk
    • Platform android-32, build-tools 32.1.0-rc1
    • Java binary at: D:\Android\AndroidStudio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)
    • All Android licenses accepted.

[√] Chrome - develop for the web
    • Chrome at C:\Program Files\Google\Chrome\Application\chrome.exe

[√] Visual Studio - develop for Windows (Visual Studio Community 2022 17.1.2)
    • Visual Studio at C:\Program Files\Microsoft Visual Studio\2022\Community
    • Visual Studio Community 2022 version 17.1.32319.34
    • Windows 10 SDK version 10.0.20348.0

[√] Android Studio (version 2021.1)
    • Android Studio at D:\Android\AndroidStudio
    • Flutter plugin can be installed from:
       https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
       https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)

[√] IntelliJ IDEA Ultimate Edition (version 2020.3)
    • IntelliJ at C:\Program Files\JetBrains\IntelliJ IDEA 2020.3.4
    • Flutter plugin can be installed from:
       https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
       https://plugins.jetbrains.com/plugin/6351-dart

[√] Connected device (3 available)
    • Windows (desktop) • windows • windows-x64    • Microsoft Windows [Version 10.0.19042.985]
    • Chrome (web)      • chrome  • web-javascript • Google Chrome 99.0.4844.84
    • Edge (web)        • edge    • web-javascript • Microsoft Edge 99.0.1150.55

[√] HTTP Host Availability
    • All required HTTP hosts are available

• No issues found!

How to solve this problem

Client does not have required privileges. errno = 1314

Are you running this from a command line?  Try running the powershell in elevated mode (Administrator).  If you see this error in vscode or android studio try running either as administrator to see if the problem goes away.
Also turn on developer mode if you haven't already

Client does not have required privileges. errno = 1314

Are you running this from a command line? Try running the powershell in elevated mode (Administrator). If you see this error in vscode or android studio try running either as administrator to see if the problem goes away.
Also turn on developer mode if you haven't already

My computer developer mode is on, and try running the powershell in elevated mode (Administrator), A new problem has arisen.
Flutter assets will be downloaded from https://storage.flutter-io.cn. Make sure you trust this source! Cannot create link, path = 'C:\Users\linjianchou\AppData\Local\Pub\Cache\_temp\dir8b0a125d\macos\Classes\FlutterBluePlugin.h' (OS Error: access denied, errno = 5) Running "flutter pub get" in ismp_app... pub get failed (66; , errno = 5))

Hi @K1IRVING, Thanks for filing the issue. Does this issue occur with the newly created flutter project too? Try to change the location of the project may be on a Desktop and see if it works. if it doesn't then,
please try running flutter pub cache repair.

Hi @K1IRVING, Thanks for filing the issue. Does this issue occur with the newly created flutter project too? Try to change the location of the project may be on a Desktop and see if it works. if it doesn't then, please try running flutter pub cache repair.

Hi @maheshmnj, Thank you for your answer. I am executing the command with the company's project not the newly created one, I change the project location on the desktop and it still doesn't work, if I run flutter pub cache repair it doesn't work either. flutter pub cache repair...

I am unable to reproduce the issue. Labeling this issue for further investigation from the team.
cc: @christopherfujino

Cannot create link, path = 'C:\Users\linjianchou\AppData\Local\Pub\Cache\_temp\dirc2beee1f\macos\Classes\FlutterBluePlugin.h' (OS Error: Client does not have required privileges. errno = 1314)
@K1IRVING does your user have write permissions on the C: drive?
Also, are you running these commands as user linjianchou?

Cannot create link, path = 'C:\Users\linjianchou\AppData\Local\Pub\Cache\_temp\dirc2beee1f\macos\Classes\FlutterBluePlugin.h' (OS Error: Client does not have required privileges. errno = 1314)
@K1IRVING does your user have write permissions on the C: drive?
Also, are you running these commands as user linjianchou?

I move flutter sdk location to E: drive, and user(linjianchou) have write permissions on the E: drive, When i run flutter pub get on android studio, console print:
E:\flutter_sdk\flutter\bin\flutter.bat --no-color pub get Running "flutter pub get" in ismp_app...                         Cannot create link, path = 'E:\flutter_sdk\flutter\.pub-cache\_temp\dir80a080c6\macos\Classes\FlutterBluePlugin.h' (OS Error: access denied, errno = 5) pub get failed (66; , errno = 5)) Process finished with exit code 66
How to solve this problem.

I'm stumped :). Hopefully the pub team will have insights at https://github.com/dart-lang/pub/issues/3384

@K1IRVING more context on https://github.com/dart-lang/pub/issues/3384#issuecomment-1118318633. Sounds like it may be an issue with the package you're using.

Closing this as it looks like the issue is upstream in pub. The issue is being tracked in https://github.com/dart-lang/pub/issues/3384, please follow that issue for updates.


Create French strings_bookmark_history.xml

Oooh, it failed... Can you please doublecheck your file, the error occurs in line 1, char 11.

@Primokorn could you please take a look :D

It should be fixed

It should be fixed

Yeah, it works now.


JsonApiSerializer.Exceptions.JsonApiFormatException

Hello, after updating from v1.7.0 to v1.7.2 I get this exception when I execute JsonConvert.SerializeObject(postData, new JsonApiSerializerSettings()):

JsonApiSerializer.Exceptions.JsonApiFormatException: Expected Id property to be a string or primitive but found it to be ''. The values of the id member MUST be a string

My postData is a class that inherits from a BaseDTO that looks like this:
public class BaseDTO : BindableBase
{
	[JsonIgnore]
	public int Id
	{
		get
		{
			if (int.TryParse(sId, out int id))
			{
				return id;
			}

			return 0;
		}
		set { sId = value.ToString(); }
	}

	/// <summary>
	/// Workaround: json:api only works if id is a string
	/// </summary>
	[JsonProperty("id")]
	internal string sId { get; set; }
}

It always worked up until v1.7.0. What changed, shouldn't that keep working as before at least?

😨 Yes that should be working.
1.7.2 was a minor change to fix a bug where int->string conversions on Ids were not occurring on relationships, but it included some refactoring of Id processing code. There must be tests missing around null ids
Will fix this ASAP!

Thanks @alex-davies !
Yes it has to do with null Ids because it happens when I serialize objects during creation, so the Id is null.

And it looks like in iOS it's a problem also in v1.7.0

It also seems to happen in v1.7.0 but only in iOS...

Issue should be solved in 1.7.3 (https://github.com/codecutout/JsonApiSerializer/pull/104)
Not sure about your iOS issue, are you using the serializer in xamarin?

Also with the later versions of the library you no longer need to convert int ids to string, it will now output ints as strings when serialising

Thank you! After a "clean solution" i rebuilt it and it worked in iOS on v1.7.0
So i can just leave public int Id {get; set;} ?

Btw, this is an awesome package, you did a great job!

Not sure if v1.7.0 was supposed to work with Id as an int only, but i tried and i got this exception:

{System.InvalidCastException: Specified cast is not valid.   at (wrapper castclass) System.Object.__castclass_with_cache(object,intptr,intptr)   at JsonApiSerializer.Util.WriterUtil.ShouldWriteProperty[T] (System.Object value, Newtonsoft.Json.Serialization.Json…}

I'll try again once i can install v1.7.3


Add HSvm to LTS-9

HSvm package has been refreshed to be buildable with GHC 8.0.2 and 8.2.1. Put to github for better collaboration and fixed few bugs in marshalling.

I moved this to the LTS repo https://github.com/fpco/lts-haskell/issues/68


First Missing Positive - LeetCode (Hard)

Aim
Want to add a solution of "First Missing Positive"
Kindly assign me this problem. I would like to add my solution to this problem in C++ in an easy way.
Details
Given an unsorted integer array nums, find the smallest missing positive integer.
You must implement an algorithm that runs in O(n) time and uses constant extra space.
Example 1:
Input: nums = [1,2,0]
Output: 3
Example 2:
Input: nums = [3,4,-1,1]
Output: 2
Example 3:
Input: nums = [7,8,9,11,12]
Output: 1
Programming language

[ ] C
[ ] C++
[ ] Java
[ ] Python

Please assign me this issue under LGMSOC'21

@ravikr126 Please Assign me this issue!


move this cookbook under opscode-cookbooks

+1
Whats the status of this cookbook? Im keen to use this, but it looks like its half finished?

It's currently in a POC state... it's due for a full rewrite soon.

@someara When do you think that will happen? Im tempted to at least attempt to deploy a kubernetes cluster with it now.

Some time in January.
On Tue, Dec 22, 2015 at 3:29 PM, Will Salt<EMAIL_ADDRESS>wrote:

@someara https://github.com/someara When do you think that will happen?
Im tempted to at least attempt to deploy a kubernetes cluster with it now.
—
Reply to this email directly or view it on GitHub
https://github.com/andrewelizondo/kubernetes/issues/5#issuecomment-166722576
.

@someara are you guys still working on this cookbook?

Finally!


feat: support insert into for mysql

seems good. is there any tresting that we can/should do/add?

There is another issue to add tests for the datasource inserts

There is another issue to add tests for the datasource inserts

great, lets do this!


BigQuery connector error with single result_mapping that is type date

For example:
"result_mappings": "title='{company}',body='{company} raised ${raisedamt} series {round} on {fundeddate}. The company is located in {city} {state} and has {numemps} employees.',url=permalink,date_published=fundeddate,fundeddate,NO_PAYLOAD",
This will cause this error:
[2023-03-07 20:25:46,487: ERROR/ForkPoolWorker-8] federate[2ba8cc5e-300a-43da-924d-86a855521319]: BigQuery_115_14: Object of type date is not JSON serializable [2023-03-07 20:25:46,487: INFO/ForkPoolWorker-8] federate[2ba8cc5e-300a-43da-924d-86a855521319]: BigQuery_115_14: save_results() [2023-03-07 20:25:46,487: INFO/ForkPoolWorker-8] federate[2ba8cc5e-300a-43da-924d-86a855521319]: BigQuery_115_14: Result.create() [2023-03-07 20:25:46,487: ERROR/ForkPoolWorker-8] federate[2ba8cc5e-300a-43da-924d-86a855521319]: tasks.py: Error: TypeError: Object of type date is not JSON serializable
This is likely because date handling in MappingResultProcessor is only applied during swirl=source mapping

Fixed in 1.10


Fix cross origin access in import-geo endpoint, in broker

PR raise here: https://github.com/ebi-ait/ingest-broker/pull/30


Compile error

Hi,
the latest version (June 02) throws an error when I try to compile:
brew upgrade
==> Upgrading 1 outdated package, with result:
neomutt/neomutt/neomutt 20170602
==> Upgrading neomutt/neomutt/neomutt --with-s-lang --with-notmuch-patch --with-libidn
==> Cloning https://github.com/neomutt/neomutt.git
Updating /Users/andreas/Library/Caches/Homebrew/neomutt--git
==> Checking out tag neomutt-20170602
==> ./prepare --prefix=/usr/local/Cellar/neomutt/20170602 --with-ssl=/usr/local/opt/openssl --with-sasl --with-gss --with-tokyocabinet --with-slang --enable-not
==> make
Last 15 lines from /Users/andreas/Library/Logs/Homebrew/neomutt/02.make:
		perl ./gen-map-doc ./manual.xml.tail ../OPS* \
	) > manual.xml
sed -e 's,[@]docdir[@],/usr/local/Cellar/neomutt/20170602/share/doc/mutt,' ./Muttrc.head > Muttrc
clang -E -I. -I.. -I/usr/local/Cellar/neomutt/20170602/include -I.. -DSYSCONFDIR=\"/usr/local/Cellar/neomutt/20170602/etc\" -DBINDIR=\"/usr/local/Cellar/neomutt/20170602/bin\" -I/usr/local/opt/openssl/include -D_MAKEDOC -C ../init.h | ./makedoc -c >> Muttrc
xsltproc --nonet -o manual.html ./html.xsl manual.xml
xsltproc --nonet ./chunk.xsl manual.xml > /dev/null 2>&1
I/O error : Attempt to load network entity http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl
warning: failed to load external entity "http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl"
compilation error: file ./html.xsl line 3 element import
xsl:import : unable to load http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl
make[2]: *** [manual.html] Error 5
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [index.html] Error 5
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

If reporting this issue please do so at (not Homebrew/brew or Homebrew/core):
https://github.com/neomutt/homebrew-neomutt/issues

Sorry, that's an extra build dependency.
You need to install the DocBook DTDs:

Fedora package: docbook-dtds
Debian package: docbook-xsl

Or you can ignore the docs: ./configure --disable-doc

Homebrew?  Ignore the (deleted) suggestions :-)
You need the DocBook DTDs.
I added "docbook" and "docbook-xsl" to the formula, but that didn't seem to help.
Unfortunately, I don't have Mac to play with and my expert has very little free time.
If you figure out the problem, please let me know and I'll fix the formula.

Hi, I'd love to help but I don't know how to debug/fix formulas :/

This worked: https://github.com/Homebrew/legacy-homebrew/issues/45020

I can confirm that @andreas-bulling solution works. I just upgraded neomutt after exporting XML_CATALOG_FILES.

With the change in the PR I just submitted the build completes properly:
==> Upgrading 1 outdated package, with result:
neomutt/neomutt/neomutt 20170602
==> Upgrading neomutt/neomutt/neomutt
==> Cloning https://github.com/neomutt/neomutt.git
Updating /Users/jasperla/Library/Caches/Homebrew/neomutt--git
==> Checking out tag neomutt-20170602
==> ./prepare --prefix=/usr/local/Cellar/neomutt/20170602 --with-ssl=/usr/local/opt/openssl --with-sasl --with-gss --with-tokyocabinet --disable-debug
==> make
==> make install
🍺  /usr/local/Cellar/neomutt/20170602: 124 files, 7.9MB, built in 56 seconds
Removing: /usr/local/Cellar/neomutt/20170428... (113 files, 3.3MB)
==> This operation has freed approximately 3.3MB of disk space.

I've merged @jasperla's fix.


Arrow Glacier spec

Adds a spec placeholder for Arrow Glacier, as agreed upon on AllCoreDevs 123 https://github.com/ethereum/pm/issues/391

Codecov Report

Merging #362 (507e6bc) into master (d414efa) will increase coverage by 1.41%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #362      +/-   ##
==========================================
+ Coverage   94.07%   95.49%   +1.41%
==========================================
  Files          13       46      +33
  Lines         827     2441    +1614
==========================================
+ Hits          778     2331    +1553
- Misses         49      110      +61

Flag
Coverage Δ

unittests
95.49% <ø> (+1.41%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

src/ethereum/base_types.py
89.13% <0.00%> (-4.03%)
:arrow_down:

src/ethereum/vm/__init__.py

src/ethereum/eth_types.py

src/ethereum/trie.py

src/ethereum/vm/instructions.py

src/ethereum/spec.py

src/ethereum/vm/interpreter.py

src/ethereum/vm/error.py

src/ethereum/vm/stack.py

src/ethereum/vm/gas.py

... and 47 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d414efa...507e6bc. Read the comment docs.


Carrierwave/gridfs attempts to connect to localhost

Could have been broken in a recent merge

Mounting gridfs as a route instead of via middleware for heroku

Any reason not to mount gridfs in routes.rb for the main repo? Seems to work well in the heroku branch.

Seems fine to me.


Update for Org store GA

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

powerbi-docs/service-admin-portal.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

@tsikiksr : Thanks for your contribution! The author, @markingmyname, has been notified to review your proposed change.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

powerbi-docs/service-admin-portal.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Please check the spelling, I noticed vesrion instead of version.

@tsikiksr : Thanks for your contribution! The author, @markingmyname, has been notified to review your proposed change.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

powerbi-docs/service-admin-portal.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Close PR, please.  Creating a new PR for this change.

closing per @markingmyname


Prevent UnionArray with Repeated Type IDs

Is your feature request related to a problem or challenge? Please describe what you are trying to do.

Currently DataType::Union has no protection against the same type ID appearing multiple times in its DataType.
Describe the solution you'd like

We should probably validate that the type_ids are unique, and prevent constructing an invalid DataType
Describe alternatives you've considered

We could not do this, much like currently permit invalid DataType::Decimal #2362
Additional context

Could I pick this ticket up?

Should we guarantee that typeid is unsigned? The current implementation does not guarantee it.

Should we guarantee that typeid is unsigned

The arrow format specifies the following - https://arrow.apache.org/docs/format/Columnar.html#union-layout

A buffer of 8-bit signed integers. Each type in the union has a corresponding type id whose values are found in this buffer. A union with more than 127 possible types can be modeled as a union of unions.

So they should be signed integers, but never negative :sweat_smile:. Most likely this was originally a workaround for Java

label_issue.py automatically added labels {'arrow'} from #4070

label_issue.py automatically added labels {'parquet'} from #3981


ENH: fix the probabilityMap RegistrationToSubject option

@reginakim I'm looking through old branches.  Could you please look through all the items in the list of branches you own and delete outdated items or make issues pointing to branches that still have value:
https://github.com/BRAINSia/BRAINSTools/branches/all
Thanks,
Hans


System-tests: Use bash explicitly

On Ubuntu, /bin/sh != /bin/bash.  Update system-tests to only use
bash for testing consistency across platforms.
Signed-off-by: Chris Evich<EMAIL_ADDRESS>

LGTM

/lgtm
/approve


Feature Request: "Do nothing" (no-op) moving action

It would be nice to support a no-op moving action. In my case, I only want the rule to only apply labels.

Looks like this is a dupe of https://github.com/ranmocy/gmail-automata/pull/29