Publisher table improvements

Add gray question marks for table headers with tooltips, close #28
Add Open Access column to publishers table, close #29

@dhimmel you can check demo at http://arielrodriguezromero.com/scihub/#/publishers
If these are ok, I'll focus next on the Journal specific data views from #14. And also I was thinking it may be a good idea to improve the design a bit, and maybe use the color scheme from the official scihub site. What do you think?

And also I was thinking it may be a good idea to improve the design a bit, and maybe use the color scheme from the official scihub site. What do you think?

All for it! Feel free to do this before journal-specific views.
Another aesthetics idea is would it be possible to make the decimals in percents smaller. So like 99.99%. Right now the two decimals add lots of numbers that make the tables harder to browse quickly. If this isn't practical or won't be good, don't worry about it... just an idea. (Also can do in different PR if desired). Let's get this current one merged soon.

Did you check our percent inactive as well? This could be interesting as well. Do we have space?

Yes, I think we can add another column. From where can I get the percent inactive??

@arielsvn feel free to do the further enhancements in a future PR. In the interest of time, I'm okay with merging this now. What do you think?

@dhimmel Let me try to finish the following changes today, I think it may be good to include them in this PR:

Journals is sorting like a string not an int.
Change Open Access tooltip to "The percent of the publisher's articles that are in open access journals. Note that open access articles in hybrid journals do not count towards this measure."
Add percent inactive column

And in a future one we can have:

Use bootstrap tooltips directly
Cosmetic improvements
Journals Specific views

@dhimmel take a look at http://arielrodriguezromero.com/scihub/#/publishers I think its much better now.
Do you think the percents are better like that?

Here's a screenshot of the new look for reference:

Do you think the percents are better like that? And the order of the columns?

I definitely like the order of columns now.
The percents with decimals as superscripts took a little while to get used to. My only worry is if they confuse users. @rossmounce @cgreene @blahah, what do you think of this display style for percents?

I found them a bit confusing at first as well.
Maybe we could give the percentage in a regular xx.yy format and then just pull the "%" out from the actual content and put it into the column heading? This would remove some of the clutter in the fields while potentially still being more intuitive.

I found them a bit confusing at first as well.

I think one of the issues could be that the superscript extends beyond the top of the full-size digit. Anyways let's save these changes for another PR. I think we should merge this PR, with the two new columns and question marks.
Then another PR can perfect the style.

Yes, I agree they look a bit weird... I'm not sure about removing the "%" sign either, but we can try and compare how it looks.

@arielsvn on the mainpage can you hyperlink the study title to https://doi.org/10.7287/peerj.preprints.3100

@dhimmel I added it like this, let me know if you think we should put something more noticeable.

I can also revert the cosmetic changes to the percents from this PR, while we figure out a better solution.

I was thinking you could just hyperlink the entire title.

Yes right, that's much better. Just pushed the change @dhimmel

@arielsvn should I merge this PR? Or did you want to do anything else before merge?

Lets merge it! I added everything I wanted.
We can continue with the other changes in a new iteration.
On Thu, Jul 20, 2017 at 8:41 PM Daniel Himmelstein<EMAIL_ADDRESS>wrote:

@arielsvn https://github.com/arielsvn should I merge this PR? Or did
you want to do anything else before merge?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/greenelab/scihub/pull/31#issuecomment-316869299, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABy5iwxdxc_ZvFDt8e_k9zDWSuBrD3OQks5sP_O-gaJpZM4OZJeD
.

Did we forget to build the webapp / add the changes in docs?

Yeah just checked :/ it seems to be only the last conmit with the link, if
you want you can add it by running "npm run build" on the webapp directory.
If not I'll add it later when I'm home.
On Thu, Jul 20, 2017 at 10:47 PM Daniel Himmelstein <
<EMAIL_ADDRESS>wrote:

Did we forget to build the webapp / add the changes in docs?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/greenelab/scihub/pull/31#issuecomment-316887146, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABy5ixnlB3yBcUY_PvpwxEBF7JkVd4s3ks5sQBE9gaJpZM4OZJeD
.

Yeah, I'm afraid I'm not a 'fan' of the superscripts. I just read it as "97 to the power 32"
I think using KISS principles would help.  Superscript is a nice idea and in some places it does work e.g. supermarket price lables, but I dont think it works here imho.
97.32 is universally understandable.

you want you can add it by running "npm run build" on the webapp directory.

Done in https://github.com/greenelab/scihub/commit/bafb56cfa272cf16fca5e16f267f1a583c0e5ef9

Yeah, I'm afraid I'm not a 'fan' of the superscripts. I just read it as "97 to the power 32". I think using KISS principles would help. Superscript is a nice idea and in some places it does work e.g. supermarket price labels, but I dont think it works here imho.

Thanks @rossmounce for the input. We'll revert something more KISS. @arielsvn I'm thinking only 1 decimal precision is the way to go.

I'm thinking only 1 decimal precision is the way to go.

Ok, lets do that! I like it more that way too


Get chromedriver via nix

We used to download chromedriver via a script because of some nixos issues. I believe that pulling chromedriver directly in our flake.nix should work fine - instead of trying to tie it to the version of Chrome we already have installed.

[x] Test in CI
[x] Test on Darwin
[x] Test on NixOS

NixOS confirmed by @shazow


ISSUE#2.0 - LEO - ISSUE SELECTION

What would you like to Propose?

My proposal is to implement an algorithm that finds the majority element in an array, where the majority element is defined as the element that appears more than half of the time.
Issue details
The algorithm uses a candidate and a counter. The algorithm selects a candidate and it counts its occurrences using the counter. It verifies if the candidate is actually the one with the most occurrences.
Additional Information
No more additional information
[FEATURE REQUEST] Add Moore's Voting Algorithm TheAlgorithms#5636


GDScript: variables that begin with an underscore ("_") do not count as being used, gives UNUSED_PRIVATE_CLASS_VARIABLE warning

Godot version:
4.0 master - 72aaf81518253e25f28b3a23b5d3509e1264a5ad
Issue description:
If a variable's name starts with an underscore it will not count towards being used (from the tests I've done) and thus produce a warning, UNUSED_PRIVATE_CLASS_VARIABLE, even if it is used.
Steps to reproduce:
var _test_var: int = 2
var another_var: int = 5

func test() -> void:
	another_var = _test_var

I can confirm this on commit https://github.com/godotengine/godot/commit/5e726d8d2025f1bc52299894230d94ef5972cea4. This doesn't occur on 3.2.3.

This should be fixed by https://github.com/godotengine/godot/pull/52329 :)


Stability (cdc) Improve the stability of TiCDC

How to define stability of TiCDC?
TiCDC as a distributed system, it should continuously provide service with predictable replication lag under any reasonable situations like single TiCDC node failure, single upstream TiKV node failure, single upstream PD node failure, planned rolling upgrade/restart of TiCDC or upstream TiDB cluster, temporarily network partition between one CDC node and other CDC nodes, etc. TiCDC should recover the replication lag by itself quickly and tolerant different resilience cases.
Expected replication lag SLO under different cases

Category
Case Description
Expected Behavior

Planned Operations
Rolling upgrade/restart TiCDC
replication lag < 5s

Scale-in/scale-out TiCDC
replication lag < 5s

Rolling upgrade/restart upstream PD
replication lag < 5s

Rolling upgrade/restart upstream TiKV
replication lag < 10s

Scale-in/scale-out upstream TiDB
replication lag < 5s

Rolling upgrade/restart downstream Kafka brokers
begin to sink ASAP kafka resumed

Rolling upgrade/restart downstream MySQL/TiDB
begin to sink ASAP kafka resumed

Unplanned Failures
Single TiCDC node (random one) permanent failure
replication lag < 1min

Single TiCDC node temporarily failure for 5 minutes
replication lag < 1min

PD leader permanent failure or temporarily failure for 5 minutes
replication lag < 5s

Network partition between one TiCDC node and PD leader for 5 minutes
replication lag < 5s

Network partition between one TiCDC node and other TiCDC nodes
replication lag < 5s

Principle of prioritizing TiCDC stability issues
We treat TiCDC stability issues as following priorities

If this issue is related to data correctness or data completeness, it should be top priority(P0), we must fix them ASAP and cherry-pick them to other LTS versions.
When this issue happens, the replication/changefeed can be stuck/failed and can't recover by TiCDC itself. We should treat this category as P1 priority. Because if such an issue happens, it means we/users should handle it manually.
When this issue happens, the replication lag will increase unexpectedly a lot. This type of issue is not that critical as P1 issues, but will breach the SLO of TiCDC, we treat them as P2 issues.
Enhancements like reducing resource usage, ... we treat them as P3 priority.

Tasks Tracking

[ ] (P1) Resolve TS might be stuck @flowbehappy
[ ] (P1) Sink might be stuck

[ ] https://github.com/pingcap/tiflow/pull/10335 @zhangjinpeng1987

[ ] (P2) replication lag increase issues

[ ] https://github.com/pingcap/tiflow/issues/10341 @zhangjinpeng1987
[ ] https://github.com/pingcap/tiflow/issues/10267

[ ] (P3) enhancement

[ ] https://github.com/pingcap/tiflow/issues/10298

https://github.com/pingcap/tiflow/issues/10157 @zhangjinpeng1987  resolve ts gets stuck issue


Wrong auto-detection of relationships between tables/excludeDependencies doesn't work

I use obevo-db v7.2.0.
There are 2 sqls which should generate DB tables: Account & WhitelistedAddress.
Account.sql
//// CHANGE name=init_account
create table ACCOUNT
(
    CLIENT_ID           bigint    not null,
    WHITELISTED_ADDRESS varchar(64),
    COMP_ID             varchar(64),
    BEGIN_STRING        varchar(20),
    SUB_COMP_ID         varchar(64),
    LOCATION_ID         varchar(64),
    SYS_AUTH_ID         varchar(128),
    SYS_AUTH_SALT       varchar(64),
    SYS_AUTH_PWD        varchar(1024),
    CLIENT_TYPE int2,
    SYS_STAT int2,
    FROM_Z              timestamp not null,
    THRU_Z              timestamp not null,
    IN_Z                timestamp not null,
    OUT_Z               timestamp not null
);
GO

//// CHANGE name=add_pk
alter table ACCOUNT
    add constraint ACCOUNT_PK primary key (CLIENT_ID);
GO

//// CHANGE name=add_unq_client_id
alter table ACCOUNT ADD CONSTRAINT UNQ_CLIENT_ID UNIQUE (CLIENT_ID);
GO

//// CHANGE name=drop_whitelisted_address_column
alter table ACCOUNT DROP COLUMN WHITELISTED_ADDRESS;
GO

Whitelisted_address.sql
//// CHANGE name=init_whitelisted_address
create table WHITELISTED_ADDRESS
(
    WHITELISTED_ADDRESS varchar(255) not null,
    CLIENT_ID           bigint
);
GO

//// CHANGE name=add_wl_pk
alter table WHITELISTED_ADDRESS add constraint WHITELISTED_ADDRESS_PK primary key (WHITELISTED_ADDRESS);
GO

//// CHANGE name=add_wl_fk
alter table WHITELISTED_ADDRESS add constraint WHITELISTED_ADDRESS_fk_0 foreign key (CLIENT_ID) references ACCOUNT(CLIENT_ID);
GO

//// CHANGE name=init_whitelisted_address_idx
create index WHITELISTED_ADDRESS_IDX0 on WHITELISTED_ADDRESS (CLIENT_ID);
GO

When I try to run deployment of DB by above scripts I got following issue:
com.gs.obevo.impl.graph.GraphCycleException: Found cycles for the changes below. Please correct the object content.
You can remediate by:
    A) manually excluding false dependencies using //// METADATA excludeDependencies=A,B,C or
    B) defining appropriate dependencies using the METADATA includeDependencies or dependencies attributes
It is helpful to analyze the EXPLICIT dependency types.

Changes are marked as [objectName.changeName]
Dependency Types: EXPLICIT = marked in code, IMPLICIT = from implied deploy order within incremental table changes

Cycle #1:
    [ACCOUNT.init_account]
    => [ACCOUNT.add_pk] (IMPLICIT)
    => [ACCOUNT.add_unq_client_id] (IMPLICIT)
    => [ACCOUNT.drop_whitelisted_address_column] (IMPLICIT)
    => [WHITELISTED_ADDRESS.add_wl_fk] (DISCOVERED)
    => [WHITELISTED_ADDRESS.init_whitelisted_address_idx] (IMPLICIT)
    => [ACCOUNT.init_account] (DISCOVERED) (CYCLE FORMED)

As you can see => [WHITELISTED_ADDRESS.add_wl_fk] (DISCOVERED) such auto-detected relationship was wrong, because all what I want is just remove WHITELISTED_ADDRESS column from Account table. This wrong auto-detection is first part of problem.
Second part of problem that excludeDependencies doesn't help me to resolve issue. I tried following change:
//// CHANGE name=drop_whitelisted_address_column excludeDependencies=WHITELISTED_ADDRESS
alter table ACCOUNT DROP COLUMN WHITELISTED_ADDRESS;

but it doesn't have any effect. Obevo still resolves such statement as link to WHITELISTED_ADDRESS table.
What is the right way to use excludeDependencies?

I will aim to look at this a bit more in detail tomorrow/this weekend.
On the surface, I see a mismatch in case between your table SQL (all caps) and the file name (mixed case). They should ideally match, or at least the file name should correspond to the case-sensitivity of your DBMS type (e.g. postgres is case-insensitive but defaults object names to lowercase, whereas SQL Server is case sensitive). In your example, if you were using postgres, then I'd rename your files to lowercase. Which DBMS type are you using?

@shantstepanian actually file names are in upper case(ACCOUNT.sql & WHITELISTED_ADDRESS.sql). I just didn't think it can be important.
I use POSTGRESQL.

I'll consider relaxing the case requirement in the future. I'm not definite about it; there are pros and cons on either side
Can you please try renaming your files to lowercase? Let me know how that goes

Hi,
I was able to reproduce the issue using your example provided and found the issue
Please ignore my previous diagnosis; the case-sensitivity is not an issue. You can leave the file case upper-case as is
You have an implicit dependency in your init_account statement as well that you would need to exclude
//// CHANGE name=init_account
create table ACCOUNT
(
    CLIENT_ID           bigint    not null,
    WHITELISTED_ADDRESS varchar(64),

The cycle error message comes out a bit differently - the key line is the third line "[ACCOUNT.init_account] (DISCOVERED)". DISCOVERED and EXPLICIT dependencies are the important ones to look at.
(as an aside - the error message omits the DISCOVERED dependency type and only EXPLICIT; I will correct this)
Cycle #1:
    [WHITELISTED_ADDRESS.add_wl_fk]
    => [WHITELISTED_ADDRESS.init_whitelisted_address_idx] (IMPLICIT)
    => [ACCOUNT.init_account] (DISCOVERED)
    => [ACCOUNT.add_pk] (IMPLICIT)
    => [ACCOUNT.add_unq_client_id] (IMPLICIT)
    => [ACCOUNT.drop_whitelisted_address_column] (IMPLICIT)
    => [WHITELISTED_ADDRESS.add_wl_fk] (DISCOVERED) (CYCLE FORMED)

You can add the excludeDependencies to both the CHANGE entries in that file to fix it
//// CHANGE name=init_account excludeDependencies=WHITELISTED_ADDRESS
create table ACCOUNT
(
    CLIENT_ID           bigint    not null,
    WHITELISTED_ADDRESS varchar(64),

Let me know if that works for you

@shantstepanian it works, thanks!

Great to hear!
I'll leave this ticket open to track the work to clarify the cycle error message

Committed the fix. Will be available in the next release. Closing this issue


Various refactors and bug fixes around ld annotation and pics

PR is functional with PICS performed against all the study-locus in GCST000758. Comparison of posterior probabilities of study-locus 12_124002131_A_G against PICS2 website shows:

Codecov Report

Merging #152 (46b2020) into main (f60e720) will increase coverage by 0.16%.
The diff coverage is 84.61%.

@@            Coverage Diff             @@
##             main     #152      +/-   ##
==========================================
+ Coverage   90.84%   91.01%   +0.16%
==========================================
  Files          66       66
  Lines        1431     1424       -7
==========================================
- Hits         1300     1296       -4
+ Misses        131      128       -3

Files
Coverage Δ

src/otg/dataset/study_locus.py
100.00% <100.00%> (ø)

src/otg/datasource/gwas_catalog/associations.py
100.00% <ø> (ø)

src/otg/method/ld.py
94.44% <100.00%> (+0.32%)
:arrow_up:

src/otg/method/pics.py
100.00% <100.00%> (+7.54%)
:arrow_up:

src/otg/gwas_catalog.py
57.14% <33.33%> (+1.58%)
:arrow_up:

... and 1 file with indirect coverage changes


Rename trait functions

Since we also need name and type pairs for structs, it makes sense to rename TraitFunction to something more general (NamedType in this case).
There are also NamedExpressions and everything could be combined into a NamedElement or something similar that covers both cases. Personally I prefer this option, but the discussion is open.

I am thinking that we may also have to change the definition of the NamedType in the grammar, since in Traits we needed functions but now it is no longer the case.
NamedType: NamedType<Expression> = {
    <name:Identifier> ":" <params:TypeTermList<Expression>> "->" <value:TypeTermBox<Expression>> => NamedType { name, ty: Type::Function(FunctionType{params, value}) }
}

Then let's keep the two different grammar rules but combine the rust types?

Oh and we certainly have to allow functions, but we can just use AStruct { a: (int -> int), b: (AStruct -> bool) }, right?


Fix: Multivariate Ridge Regression coefficients

Description
Ridge penalties were passed to daal ridge training in incorrect shape, resulting only in first target's coefs being calculated accurately. This pr addresses the problem by transforming the penalties into correct shape.
Fixes # - 275

[x] I have reviewed my changes thoroughly before submitting this pull request.
[x] I have commented my code, particularly in hard-to-understand areas.
[ ] I have updated the documentation to reflect the changes, if necessary (updated in # - add PR number)
[x] The unit tests pass successfully.
[x] I have run it locally and tested the changes extensively.
[x] I have resolved any merge conflicts that might occur with the base branch.
[x] Git commit message contains an appropriate signed-off-by string (see CONTRIBUTING.md for details)
[ ] I have added a respective label(s) to PR if I have a permission for that.

/intelci: run

/intelci: run

/intelci: run

/intelci: run

/intelci: run


Revert "tree: Change method for selecting random node ranges in fuzz tests

This reverts commit 0a4e642f3b776de5f9f7cf85538cfb6041307786 / PR #21821
That PR was merged with stale PR checks (3 weeks old), and broke the internal CI pipeline.

@microsoft/fluid-cr-tree please review to unblock CI


feat(rust): add output.sourceMapFilename core

Related issue (if exists)
#2938
Summary
Manage the output path of source map files
https://webpack.js.org/configuration/output/#outputsourcemapfilename

🤖 Generated by Copilot at 0cf70ca
This pull request adds a new option sourceMapFilename to the rspack configuration file, which allows users to customize the filename of the source map files generated by the rspack_plugin_devtool plugin. It implements this option in the rspack_core, rspack_binding_options, rspack_plugin_devtool, and rspack_testing crates, and updates the JSON schema and typescript types for the rspack configuration file. It also makes some minor code improvements and updates the package.json file.

Walkthrough

🤖 Generated by Copilot at 0cf70ca

Add a new source_map_filename option to the rspack configuration file and the rspack_core crate to allow users to configure the output filename of the source map files generated by the rspack_plugin_devtool plugin (link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link)
Use the [file] placeholder syntax for the source_map_filename option to support the original filename in the template, similar to webpack (link, link)
Check the devtool option and the public_path option in the rspack_plugin_devtool plugin to handle different modes and paths for the source map files (link)
Use the ..Default::default() syntax for the AssetInfo struct initialization in the rspack_plugin_asset, rspack_plugin_copy, and rspack_plugin_html plugins to improve the code readability and maintainability (link, link, link, link)
Fix the indentation of the test case file for the source-map feature in the webpack-test directory (link, link)

General looks good to me, ready to merge after rebase

General looks good to me, ready to merge after rebase

have rebase main branch


Provide the list of latest votes

Description
As a user; I'd like to see the latest votes
Motivation
Help delegates have a better understanding about changes in the list of their voters.
Help voters get notified if the community is revoking trust from a delegate or increasing attention towards another.
Acceptance Criteria

Should list the below information
Date and time
Transaction details
Sender id
Current balance
Round
Votes

This feature is already implemented and discontinued. This issue can be closed.


Invalid assignment of ObjectType in saved_query list API

There is wrong assignment of object_type here (it should be "query" instead of "saved_query")
Due to which, saved_query list API fails to load (when used databases except on sqlite - probably because sqlite does not strictly check enum type of object_type)
How to reproduce the bug

Setup backend database  as postgres, Go to 'Saved Queries' page
You'll see an error popup right away and there are no saved queries shown.

Expected results
There should not be any error and saved queries should load fine
Actual results

Shows error popup with sql error and there is no row of saved queries.

Screenshots

Environment
(please complete the following information):
browser type and version:
superset version: 2.1.0
python version: 3.9.14
node.js version: 16.17.1
any feature flags active: TAGGING_SYSTEM
Checklist
Make sure to follow these steps before submitting your issue - thank you!

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

@Antonio-RiveroMartnez what database is your local setup running on? it works fine for SQLite. I can repro it with postgres.

Yes, I am using Postgres (You can verify in the video above for the selected Database). Are you using latest master or branch 2.1.0? If 2.1.0, could you try using latest master? Trying to see if it got already solved by some newer change after the 2.1.0 cut. Thanks @akzarma

Yeah, my bad, I was some commits behind. it seems like it got resolved in the effect of https://github.com/apache/superset/pull/23526
However, The fix (#23611 ) I provided is still needed for the Tag feature to work on saved queries (which I think is half baked for saved queries)
My fix assigns the right object_type ("query") from the available types instead of "saved_query".
https://github.com/apache/superset/blob/b820eb82353fedf92aa45f1293ac3dcf4020296d/superset/tags/models.py#L66-L74
But yeah, this issue should be closed as the steps mentioned are not reproducing the bug.
Thanks @Antonio-RiveroMartnez


Review and refactor stereo_rgb science package

Per review of stereo_rgb science package in https://github.com/terraref/computing-pipeline/issues/386, we have identified a few concerns that need to be addressed for this as an example of the new "Science package" module (for example, it should be using standard modules for csv generation and ordered dictionaries)
Completion criteria:

[ ] Review existing code, make recommendations for changes
[ ] Implement recommended changes
[ ] Submit PR
[ ] PR Merged
[ ] pytest passed, published to pypi

Reviewed and merged the big PR. additional work can be done in additional PRs.


[1.9.2] Update zlib source url

Checklist before submitting

[ ] Did you read the contributor guide?
[ ] Did you update any affected documentation?
[ ] Did you write any tests to validate this change?

Description
Fixes # (issue).
Review process to land

All tests and other checks must succeed.
At least one maintainer must review and approve.
If any  maintainer requests changes, they must be addressed.

Thanks @ArchanaShinde1.


Assembly conflict

Whenever I run any command in this module, I get the assembly conflict warning below:
WARNING: Assembly with same name "Microsoft.Identity.Client.Desktop.dll" is already loaded:
C:\Program Files\WindowsPowerShell\Modules\MSAL.PS\<IP_ADDRESS>\Microsoft.Identity.Client.Desktop.4.35.1\net461\Microsoft.Identity.Client.Desktop.dll

Ignore assembly conflict and continue importing module?
Some module functionality will not work.
[Y] Yes  [N] No  [?] Help (default is "N"): Y

Remember settings?
Module settings will be persisted in "C:\Users\•••••••\AppData\Roaming\MSAL.PS\config.json"
[Y] Yes  [N] No  [?] Help (default is "N"): Y

This will be remembered and not prompting within the same PowerShell window, but on a new PowerShell window, it is prompting the same warning again.
I tried providing the module settings on import, which suppressed the prompt, but the warning still shows.  At least now I can schedule the script to run without stuck at the interactive prompt.  But what should I do to fix this warning?
Import-Module -Name MSAL.PS -ArgumentList @{ 'dll.lenientLoading' = $true; 'dll.lenientLoadingPrompt' = $false }
Thanks,
Anson

For some reason, the assembly conflicts with itself on certain versions of Windows. I added a fix to ignore the self-conflict. However, when there is a legitimate conflict, the warning will always display. The remember setting is only there to allow you continue without interaction. There was also a bug in writing the settings to file which is why it prompted you every time. That should be fixed now as well.


python312Packages.types-requests: <IP_ADDRESS>40622 -> <IP_ADDRESS>40712

Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 329504 run on x86_64-linux 1

4 packages marked as broken and skipped:

python311Packages.tabcmd
python311Packages.tabcmd.dist
python312Packages.tabcmd
python312Packages.tabcmd.dist

44 packages built:

cwltool
cwltool.dist
gphotos-sync
gphotos-sync.dist
python311Packages.cohere
python311Packages.cohere.dist
python311Packages.cwl-upgrader
python311Packages.cwl-upgrader.dist
python311Packages.cwl-utils
python311Packages.cwl-utils.dist
python311Packages.djangorestframework-stubs
python311Packages.djangorestframework-stubs.dist
python311Packages.jsonargparse
python311Packages.jsonargparse.dist
python311Packages.llmx
python311Packages.llmx.dist
python311Packages.pyarr
python311Packages.pyarr.dist
python311Packages.schema-salad
python311Packages.schema-salad.dist
python311Packages.types-requests
python311Packages.types-requests.dist
python311Packages.unstructured-api-tools
python311Packages.unstructured-api-tools.dist
python312Packages.cohere
python312Packages.cohere.dist
python312Packages.cwl-upgrader
python312Packages.cwl-upgrader.dist
python312Packages.cwl-utils
python312Packages.cwl-utils.dist
python312Packages.djangorestframework-stubs
python312Packages.djangorestframework-stubs.dist
python312Packages.jsonargparse
python312Packages.jsonargparse.dist
python312Packages.llmx
python312Packages.llmx.dist
python312Packages.pyarr
python312Packages.pyarr.dist
python312Packages.schema-salad
python312Packages.schema-salad.dist
python312Packages.types-requests
python312Packages.types-requests.dist
python312Packages.unstructured-api-tools
python312Packages.unstructured-api-tools.dist


[ISSUE #660] Add namespace in java client

Which Issue(s) This PR Fixes

Fixes #660
Brief Description
Add namespace in java client

How Did You Test This Change?

Codecov Report
Attention: 18 lines in your changes are missing coverage. Please review.

Comparison is base (20c5fba) 55.57% compared to head (da868b6) 46.73%.
Report is 14 commits behind head on master.

Files
Patch %
Lines

...mq/client/java/impl/consumer/PushConsumerImpl.java
27.27%
8 Missing :warning:

...cketmq/client/java/impl/producer/ProducerImpl.java
25.00%
6 Missing :warning:

.../client/java/impl/producer/PublishingSettings.java
62.50%
3 Missing :warning:

...tmq/client/java/message/PublishingMessageImpl.java
0.00%
1 Missing :warning:

Additional details and impacted files
@@             Coverage Diff              @@
##             master     #661      +/-   ##
============================================
- Coverage     55.57%   46.73%   -8.85%
- Complexity      663      668       +5
============================================
  Files           259      207      -52
  Lines         15460    12022    -3438
  Branches       3757     3405     -352
============================================
- Hits           8592     5618    -2974
+ Misses         6623     6158     -465
- Partials        245      246       +1

Flag
Coverage Δ

java
62.94% <70.00%> (+0.32%)
:arrow_up:

nodejs
?

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

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


[NFR]: Refactor Phalcon\Mvc\View\Volt

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I am always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

Now that Phalcon is moving to PHP-space, might this be a good time to transition away from Volt and to something more widespread - like Twig?
I realize v5 is intended to have parity with v4, so this might need to wait until v5.1 or v6, but I don't see the point of having Yet-Another-PHP-Template-Library that behaves very much like Twig.

Now that Phalcon is moving to PHP-space, might this be a good time to transition away from Volt and to something more widespread - like Twig?
I realize v5 is intended to have parity with v4, so this might need to wait until v5.1 or v6, but I don't see the point of having Yet-Another-PHP-Template-Library that behaves very much like Twig.

No please don't do that. Volt is good enought! https://github.com/phalcon/phalcon/discussions/96

@quasipickle Volt will continue to exist. It probably will be separated into own repository to add in project when you are using it, but in v5 it will be bundled as it is in v4.

Implemented https://github.com/phalcon/phalcon/pull/505


Trouble re-installing crouton

I have previously installed crouton with no problems at all. However I have since turned off developers mode clearing the local data.
I have tried to revert back to developers mode and re-install crouton but nothing seem to happen. I have pasted the command lines I've used below. If somebody can tell what I'm doing wrong I would appreciate it.
Welcome to crosh, the Chrome OS developer shell.
If you got here by mistake, don't panic!  Just close this tab and carry on.
Type 'help' for a list of commands.
crosh> shell
chronos@localhost / $ sudo sh -e ~/Downloads/crouton -t xfce
chronos@localhost / $

I am running into the same issue. The crouton version that I downloaded just a few moments ago is 1-20161116131524~master:9db73043.

@chcschmid,
Which issue?
Please give us more details -

Did you also get out of and back into Dev mode?
When you run crouton do get no error and no output?
or
It says sh : can t open /home/chronos/user/downloads/crouton?

-DennisL

I did get out of and back into Dev mode.
I downloaded the crouton yesterday evening and ran the following command
from 'shell'...
sudo sh -e ~/Downloads/crouton -r trusty -t xfce-desktop keyboard, chrome
It starts the installation and gets to 100%, then I get the following
result...
[image: 1.png]
[image: 2.png]
I checked for /usr/local/chroots to see if symlink existed, but the chroot
folder doesn't even exist in local.

Christiaan
On Mon, Nov 21, 2016 at 6:27 AM DennisL<EMAIL_ADDRESS>wrote:

@chcschmid https://github.com/chcschmid,
Which issue?
Please give us more details -

Did you also get out of and back into Dev mode?
When you run crouton do get no error and no output?
or
It says sh : can t open /home/chronos/user/downloads/crouton?

-DennisL
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dnschneid/crouton/issues/968#issuecomment-261938269,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHqCGtvNabhVrL-qXp-XOEGDvnFJZPyqks5rAZxCgaJpZM4CUY4T
.

@chcschmid,

sudo sh -e ~/Downloads/crouton -r trusty -t xfce-desktop keyboard, chrome

I don't know if the command-line you show above is exactly what you typed but you need a comma ',' between targets and without any spaces (I think) - like:

sudo sh ~/Downloads/crouton -r trusty -t xfce-desktop,keyboard,chrome

It starts the installation and gets to 100%, then I get the following
result...

That doesn't sound like that was the hangup though if you got '100%'.
Your images/links above don't seem to work so we can't tell where it's failing.
Sorry,
-DennisL

Ah, your solution was what I needed. I was following instructions from a blog I found and the command used there didn't have a comma between xfce-desktop and keyboard. Thanks for your help @DennisLfromGA! It seems to be working now.

@chcschmid, Cool! Glad I could help.

crouton still isnt working its saying illegal :/ wouldnt mind but i really wanna be able to use windows

@sammymay97,
This issue was closed literally years ago.
If you are having trouble reinstalling crouton please follow this troubleshooting guide:

Common issues and reporting

Then if you still have are having problems please open a new issue and tell us in detail what is wrong and what errors you're getting.
Hope this helps,
-*DennisLfromGA


Make the c:injector Lightning Component read direct to native

In cases where no binding is found it might be preferable to have the injector redirect to the native UI for the given action... ?

@afawcett I'm not sure what you mean by "redirect to the native UI for the given action"?


Feature request: manually set the maximum balance value

Thank you for the extension!
The only complain I've got is that it gives me too much time to procrastinate since it keeps adding minutes to my balance even when I'm away (and therefore not working).
Could you please add an option to manually set the maximum possible balance value? That would be  simple yet sufficient solution.
Thanks in advance.

I have the opposite problem - knowing that my balance won't keep accumulating makes me feel like I ought to start taking longer breaks to use it up. So I want a larger max. Same solution, though!


Extension Host Failure - Error interaction with MATLAB code on macOS Catalina

Version: 1.47.3
Commit: 91899dcef7b8110878ea59626991a18c8a6a1b3e
Date: 2020-07-23T13:08:29.692Z (2 wks ago)
Electron: 7.3.2
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Darwin x64 19.6.0
Note: Tested Insiders and it suffers from the same issue.
Steps to Reproduce:

Have MATLAB 2018 or later installed on your system.
Open VS Code via /Applications/Visual Studio Code.app (Launchpad, Finder, or Spotlight)
Observe Extension Host crash with the following error:

dyld: Symbol not found: _mecab_get_feature  Referenced from: /System/Library/PrivateFrameworks/CoreNLP.framework/Versions/A/CoreNLP  Expected in: /Applications/MATLAB/MATLAB_Runtime/v95/bin/maci64/libmecab.dylib in /System/Library/PrivateFrameworks/CoreNLP.framework/Versions/A/CoreNLP

Does this issue occur when all extensions are disabled?: No
It should be noted that the issue does not occur when launched via Terminal at all (even when extensions are enabled). It appears to be something related to the app wrapper.
Workaround:

Open via Terminal using /Applications/Visual\ Studio\ Code.app/Contents/Resources/app/bin/code instead of launching using the app launcher itself.

So this only happens when extensions are installed? Which one causes this?

@deepak1556 This looks similar to #103057
@mko Have you by any chance customized your DYLD_LIBRARY_PATH ?

@alexdima I can’t check right now. I’ll check when I’m able to, but I know that MATLAB requires its compiler and related libraries to be added to the DYLD_LIBRARY_PATH in order to run without having to append 100+ characters to every command. This is not a “package-specific error unrelated to VSCode” though. VSCode, unlike any other software on the system that accesses a PATH variable has a failure case caused when a developer does an extremely common developer thing: that is, extends their path. To dismiss it as just a package issue instead of doing the work to find the bug in your own code to prevent the Extension Host from crashing during this use case means you block off a significant segment of users who cannot change the way your system interacts with the rest of theirs.

Here is what I could find about DYLD_LIBRARY_PATH -- https://stackoverflow.com/a/3172515 -- I personally have never used that.
In my opinion, would it not make sense to define DYLD_LIBRARY_PATH only when invoking the MATLAB compiler and not globally?
VS Code is built with Electron, which is built with Chromium. Perhaps you define that environmental variable, and that leads to Electron/Chromium respecting it (maybe it is an OS thing and outside of Electron/Chromium's control?) and attempting to load a symbol from a dynamic library found in the path you have defined for MATLAB? Suppose Electron/Chromium needs to load protobuf and now it finds protobuf in the path you have defined for MATLAB. It might or might not work depending on if protobuf is exactly at the same version / has the same symbols as the one expected by Electron/Chromium.
Perhaps @deepak1556 has more insights, I'm sorry this is as much as my knowledge on the subject goes.

Looking at the past issues filed and why only VSCode is affected, not other electron apps, I think I can conclude where the issue happens to be. When a GUI app is launched on mac, it would be usually via the finder or open command (launch services basically isolating the app launch) and not from the terminal which would mean the app is launched as a subprocess of it, getting the same set of environment configuration for all its process. Chromium has its own process launch management, so the renderer and other process launched don't get affected with this but since we fork the extension host process from the renderer, meaning we use the same helper executable as the renderer but with the shell environments copied to it, it eventually leads to this sort of incorrect symbol load.
This should be fixed once we land https://github.com/microsoft/vscode/pull/104470 but as a short term fix we can remove the DYLD_LIBRARY_PATH from the launch wrapper env https://github.com/microsoft/vscode/blob/master/src/vs/code/node/cli.ts#L320 so that it doesn't propagate. Thoughts @alexdima  ?

@mko How exactly have you configured DYLD_LIBRARY_PATH ? I would like to attempt to reproduce the crash such that we can come up with a potential fix.
@deepak1556 I don't think cli.ts plays any part in forking the extension host process. The fork happens here -- https://github.com/microsoft/vscode/blob/bb624e94f2a9c01b19e9ad89303b157df87ce93b/src/vs/workbench/services/extensions/electron-browser/localProcessExtensionHost.ts#L159-L167 -- We could try to unset DYLD_LIBRARY_PATH there, but before doing that change I would like to be able to reproduce the problem.

Doesn't cli.ts launch the app as a child process, so the env variables it launches gets propagated all the way down because of process.env. For example.
$ export ABC=1
$ code-insiders vscode/
$ check process.env.ABC in renderer process
$ check process.env.ABC in extension host process.

DYLD_LIBRARY_PATH is set as an environment variable in the bash profile with the following, per MATLAB Compiler Runtime instructions:
DYLD_LIBRARY_PATH=/Applications/MATLAB/MATLAB_Runtime/v95/runtime/maci64:/Applications/MATLAB/MATLAB_Runtime/v95/sys/os/maci64:/Applications/MATLAB/MATLAB_Runtime/v95/bin/maci64:/Applications/MATLAB/MATLAB_Runtime/v95/extern/bin/maci64:$DYLD_LIBRARY_PATH

@alexdima: I totally agree that it would make more sense to only define the updated path when MATLAB is being invoked, but that's not possible with the way that MATLAB compiled binaries work. In both our development environment and several third-party packages we have used, the MCR binaries get invoked through processes where the developer typically does not have the ability to define an environment variable. The issue that I'm seeing though is that there are no "override" symbols between the system and MATLAB (i.e. no protobuf or libjpeg or similar symbols that would be expected to have already been provided elsewhere).

As I noted previously, I'm able to get extensions working as long as I launch code directly. I doubt this affects many people, so I'm happy to provide whatever I can in debugging help to solve it the right way. Let me know if there's anything else I can provide (debug logs, bin contents, etc)

cc @bpasero

@deepak1556 @alexdima note that on Linux & macOS if we detect that VSCode is run from e.g. the dock (and not from the CLI), we use the method getShellEnvironment method to spawn a shell to get environment variables from the shell back into the process.env. The rationale is to get development related environment variables into VSCode, e.g. to support task execution.
If we want to filter DYLD_LIBRARY_PATH, it would also have to be added to that place.

Thanks @bpasero that explains why the env variable was carried over to the renderer, my understanding was incorrect.
Just remembered a past issue where there was a valid use case for DYLD_LIBRARY_PATH in tasks https://github.com/microsoft/vscode/issues/88306 , do you think this use case will continue to work if we filter it from shell env ?
This issue has to wait until https://github.com/microsoft/vscode/pull/104470 lands, the change ensures app is not launched via shell, so VSCODE_CLI wouldn't be effective. This is something that was missed, I will add it to the PR discussion.

Just remembered a past issue where there was a valid use case for DYLD_LIBRARY_PATH in tasks #88306 , do you think this use case will continue to work if we filter it from shell env ?

My understanding is that DYLD_LIBRARY_PATH might have negative impact on VSCode itself, so a solution that allows to use DYLD_LIBRARY_PATH in tasks (or anywhere else in extensions code) should support this variable exclusively for that child process, right? In other words, I do not think it is a good idea to support DYLD_LIBRARY_PATH in this scenario by adding it to the environment of VSCode itself, it should only apply to the processes that are executed that really need it.
And to clarify: If we decide to filter DYLD_LIBRARY_PATH, it would be everywhere, not just from that getShellEnvironment call.
Maybe one approach would be to filter DYLD_LIBRARY_PATH by renaming it to VSCODE_DYLD_LIBRARY_PATH and then ensuring to put it back in selected places where users really want it?

This issue has to wait until #104470 lands, the change ensures app is not launched via shell, so VSCODE_CLI wouldn't be effective. This is something that was missed, I will add it to the PR discussion.

Not sure I follow what you said, we have to ensure VSCODE_CLI is present for any invocation of VSCode from the command line.

My understanding is that DYLD_LIBRARY_PATH might have negative impact on VSCode itself, so a solution that allows to use DYLD_LIBRARY_PATH in tasks (or anywhere else in extensions code) should support this variable exclusively for that child process, right?

Yup thats correct

Maybe one approach would be to filter DYLD_LIBRARY_PATH by renaming it to VSCODE_DYLD_LIBRARY_PATH and then ensuring to put it back in selected places where users really want it?

Sounds good, but I am not familiar with the task execution system to verify if this will work fine. Atleast would be good to verify with the sample from https://github.com/microsoft/vscode/issues/88306 . Also if there are use cases, I would like to capture it in this issue.

Not sure I follow what you said, we have to ensure VSCODE_CLI is present for any invocation of VSCode from the command line.

That won't be true with https://github.com/microsoft/vscode/pull/104470 , since the app won't be invoked from the shell. We are trying to emulate the behavior of opening from finder. I just remembered that we missed VSCODE_CLI context in that PR, so wanted to capture it. I haven't thought about the way forward, we can continue the discussion in the associated issue.

Sounds good, but I am not familiar with the task execution system to verify if this will work fine. Atleast would be good to verify with the sample from #88306 . Also if there are other use cases, I would like to capture it in this issue.

👍

That won't be true with #104470

To clarify: if we switch to open command, none of the shell process environment or anything we configure in our CLI scripts ends up in the process environment of the VSCode window? That would be pretty bad and we then need an alternative for how to getting these variables in. Even when running out of sources, code.sh defines many variables:
https://github.com/microsoft/vscode/blob/46860a105b2f2e115970ad0d54f5a39d5add9cc5/scripts/code.sh#L39

To clarify: if we switch to open command, none of the shell process environment or anything we configure in our CLI scripts ends up in the process environment of the VSCode window? That would be pretty bad and we then need an alternative for how to getting these variables in. Even when running out of sources, code.sh defines many variables:

yeah thats correct, the only way I see now is to pass them via command line flags and modify process.env in the app, should figure a good solution for this.

Even when running out of sources, code.sh defines many variables:

we are not gonna change the out of sources cli wrapper, so this one should not be an issue.

@bpasero @deepak1556 I'm not 100% sure I understood your discussion above. So what is the final proposal here? Is this something that needs to be done only for the extension host process or is this something that needs to be done for the entire workbench? What is the final proposed change?

ping @bpasero @deepak1556

I talked with @deepak1556 in our Monday call and we think that removing this variable here should be fine:
https://github.com/microsoft/vscode/blob/e557e8bcc3ca6b4569eee3f6b746f00b4572db56/src/vs/workbench/services/extensions/electron-browser/localProcessExtensionHost.ts#L160
This means that the variable will never reach extensions, but my understanding is that people only want it for task execution which currently does not happen in the extension host (iirc).

Sorry missed this, thanks @bpasero @alexdima , yeah this should fix the issue.

@mko can you confirm if this issue is fixed with latest insiders https://code.visualstudio.com/insiders/

I cannot reproduce the original crash even when I set export DYLD_LIBRARY_PATH=<path>, I see no extension host crashing. What are the steps?

@bpasero From my understanding, setting the environmental variable is one part of the problem. The crash appears if there is a matching library found at that folder location. So for example, our process wants to load protobuf and then that folder has protobuf, but at a version that is not compatible, etc.

Oh ok, then maybe best to let author verify.

I’ll try verifying it this afternoon. Thanks

On Sep 4, 2020, at 4:12 AM, Benjamin Pasero<EMAIL_ADDRESS>wrote:

Oh ok, then maybe best to let author verify.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Sorry -- ended up not getting to verify until today, but I can verify this is solved.

cc: @bpasero -- Verified


Add to_posix_filename and to_win32_filename

Add two new filters with specific platform conversions.

Fixed on 2022-01-01.

Fixed on 2022-01-01.


Allow httpOnly cookie storage

Similar to #23 but with a different motivation.
To protect against XSS, I would like the option to store the JWT in an HttpOnly cookie. django-rest-framework-jwt has this feature as an optional setting but that project I believe is abandoned and also has a vulnerability due to preventing the usage of django's CSRF token (see: https://github.com/GetBlimp/django-rest-framework-jwt/pull/434). Combining an HttpOnly cookie with CSRF token would be a pretty rock solid solution.
References:
https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage
https://stackoverflow.com/questions/44133536/is-it-safe-to-store-a-jwt-in-localstorage-with-reactjs

This is super important for me going forward... and it should be for everyone who uses this project.  It SEEMS to be rather trivial to set the cookie.
Unsure what other side effects this may have.

@derek-adair I pick the cookie out in nginx and put it in the authorization header. This is a workaround, but it works for me.

I'll hopefully be submitting a PR for this in the near future!

Cool, @derek-adair .  Looking forward to seeing that!

Hey @derek-adair, are you on it? If not, I want to give it a try!

I could give it a try too, but I'm not sure how the refresh tokens come into play with cookies.. I think they don't make sense with cookies,

If both are cookied, then both would be included in each request.. which takes away little secrecy the refresh token had.
If only one of the tokens is cookied, the other will be kept in the client, which makes it vulnerable to XSS attacks. In this case, it would make more sense to leave the access token in the client, since its lifespan is shorter

So.. I guess that in order to touch the less amount of code possible, the best solution would be to cookie both tokens, but yeah, the refresh tokens doesn't add any security here

@mrodal makes a good point.  Refresh tokens are supposed to be sent over the wire less frequently (only when obtaining a new access token or access/refresh pair).  It's a bit awkward in the context of web browsers, but JWTs can potentially be used by non-browser clients as well.  The access/refresh dichotomy makes more sense in that broader scope.

IIRC, another option would be that the refresh token cookie is only set for the refresh view's path.  Then, it would only be sent over the wire for refresh requests in particular.

@mrodal it's my understanding that httpOnly + same site cookie is more secure than storing it in memory or localStorage (XSS vulnerability).
If the refresh token is not persisted in a cookie where would you suggest storing it?
   I'm almost convinced to NOT implement JWT for web browsers.  However, i'm not sure the alternative for a single page app.

IIRC, another option would be that the refresh token cookie is only set for the refresh view's path. Then, it would only be sent over the wire for refresh requests in particular.

Could you elaborate? Didn't know it was possible to do this.

Does django mitigate XSS?

If the refresh token is not persisted in a cookie where would you suggest storing it?

I would actually not use it at all when using cookies.. Since it requires extra logic in the front-end and, as I said before, I don't see the benefit from using it. This is what Im doing in a mobile app that's also going to be a spa in the future.
Take into account that storing it in the cookie makes you possibly vulnerable to CSRF attacks if you don't use CSRF tokens, since the auth token is automatically added to each request...

Does django mitigate XSS?

If you are using django templates, you are protected by default when printing data from the server side. But you could still be vulnerable if you generate content on the front-end, although last time I checked, browsers also help quite a lot to prevent these attacks.

I would actually not use it at all when using cookies
So just store the actual token for longer, make them re-auth when it expires?

Since it requires extra logic in the front-end
Man i wish i would have came to that conclusion before I implemented a replay request thing in my redux app.... ha!

This is what Im doing in a mobile app that's also going to be a spa in the future.

Right, it's clear this is where the miscommunication.

Take into account that storing it in the cookie makes you possibly vulnerable to CSRF attacks if you don't use CSRF tokens, since the auth token is automatically added to each request...

What about if you are using CSRF tokens?  Should be good is my understanding.

Jeeeeez.  So the refresh token is pretty damn useless in a browser... however....
httpOnly cookie still seems essential for the access-token.

So just make them re-auth when it expires and/or store the actual token for longer?

Make the expiration time longer.. assuming https is being used, the risk of it being captured in the middle is negligible, and since its an httpOnly cookie, from js it cant be accessed either.. the only possibility I see is an attacker gaining physical access to the device and copying the cookies, but that I believe is always present anyways

What about if you are using CSRF tokens? Should be good is my understanding

Yeah, if you are using both CSRF and httpOnly cookies for the access token you are pretty much covered
Please someone correct me if I'm missing something

@derek-adair This is what I was talking about with the cookie path.  If the refresh token is set for the refresh view path, the browser will only include a Cookie header with the refresh token when making requests to the refresh view.  So the refresh token is still used more securely and isn't sent over the wire as often as an access token.
What @mrodal is saying about CSRF also applies.  Since cookies are automatically sent with any request that matches them, they don't care about what initiated that request or from where it originated.  So you can't really tell if the user triggered the request intentionally.  You need to include the CSRF token with the request so that Django can verify the request came from an "authorized" source e.g. a redux app hosted on a trusted server.  All this stuff is bothersome but necessary.  Since JWTs are still relatively new tech, they require that you think more about the nuts and bolts of auth system and why they work the way they do.
As XSS goes, Django does provide out-of-the-box protection against it, but it's not perfect.  There are still certain cases in which it can be disabled whether intentionally or unintentionally.  You still need to think about how it could happen and verify that the possibility doesn't apply to you.

An HttpOnly Cookie access token combined with a Refresh on a certain url (refresh view) looks nice to me.
As for SPA-clients, you can protect against CSRF by setting the x-requested-with header and checking that one on the server (see https://markitzeroday.com/x-requested-with/cors/2017/06/29/csrf-mitigation-for-ajax-requests.html).
@davesque  How would you cover both web and mobile scenario's? I have the same django rest backend for web and mobile. As for mobile, it's ok to send both tokens and store them on the device (secure storage it is). When handling a web-request I want to use the cookie tokens?

I am very... confused as to the purpose of this? Why would you use JWT authentication for web when you have session cookies already? So assuming this is for the web application / the website, here's my opinion:
If anything, you're going to be implementing a lot more JS which means a new point of attack (as previously mentioned in the XSS and CSRF token misplacements). Seems more like a headache to me; providing this would be a disservice.
DRF should really only be used for mobile application and occasionally be used with AJAX on an insecure endpoint. Sure, you can tack on some IP rate limit, but, in reality, you should be using a user rate limit and sending 403 forbidden back to unauthenticated users. But with a user rate limit, you're sending refresh tokens via http which can easily be eavesdropped on... so again:
What's the point of this? Feels more like a security vulnerability to users than a practical feature.

@Andrew-Chen-Wang I just think we need both :-)
I have one API for both web and mobile, would like to use cookies for the websession part and jwt for API auth. If we can't differentiate the method (cookie vs jwt) then the jwt-token should be stored in a httponly cookie, not readable by js. In this case a few more measures need to be taken to further secure the token.
https://blog.logrocket.com/jwt-authentication-best-practices/

Shouldn't we store the refresh token rather than the access token inside the http only cookie. JWT access tokens are best stored in memory with a countdown to refresh using the refresh endpoint. If you store the access token in the http cookie, like this patch/plugin suggests, where do I store the refresh token.

I liked @davesque's idea of storing both in HttpOnly cookies but setting the refresh token cookie for the refresh path only. This way there's no need to store tokens in localStorage but the refresh token isn't sent with every request.

What's the progress on this issue?

I've made a fork using a pull request allowing httponly and merged it with the current master.
You can find it here: https://github.com/schlunsen/django-rest-framework-simplejwt

DRF should really only be used for mobile application

Definitely false.

@Andrew-Chen-Wang This is a really heated and opinionated subject to the point where some have sworn JWT is insecure by design.
You can read up on why you would want to store your tokens here.  Honsetly not sure of the quality of that article I just really am sick to death of this subject.

@schlunsen Sticking with the original package looks safer to me especially when there's still discussions about the PR. I'm no django expert, so I can't tolerate risk, thank you!

@derek-adair If you use that fork (you can pip install via a link) and deploy and publish on GitHub a project using React, Django, and SimpleJWT, then I'd love to see it! I've also added my two cents to the PR that you should probably change. If anything, you may need to just download the fork, import it into your project, and manually change a couple things.
Otherwise, regarding your comment, I agree that this is a very heated topic -- to the point that Calude Peroz, a core Django Developer, made a PR for JWT implementation only to get fired down by other core developers (mainly James Bennett) for security reasons. The link to the discussion. However, I will need to point out that the links James sent regarding security issues is not up to date with the updated RFCs AFTER they have been fixed -- luckily, PyJWT was one of the libraries to be fixed after I'd say the 30 links (including child links) out of 45 (if I can count correctly and if I even read all of them) sent.
The reason I said DRF is for mobile apps is because when I look at React + DRF websites, they all use this package and they all have the same level of implementation issues. If you can create a package that utilizes this fork, then I'd be happy to look over it! I have a Swift and Kotlin repo for using SimpleJWT here; you can make a PR there, and, in the requirements.txt, change the drf-simplejwt to the forked repo. If it's a worthy example, then the merging process can quicken.
Anyhow, tests are not enough for these kinds of packages. A production ready test is necessary. If you'd like, you can also use https://github.com/pydanny/cookiecutter-django to setup your project, deploy on Heroku or an EC2 instance or python anywhere, and testing and analyzing can be done much faster from me and Dave. Otherwise, I promise, this PR will never get merged. It's a hyped fork with no real implementation, yet.

@Andrew-Chen-Wang THANK you for this django thread.  This should be a great read and maybe there is some clarity here.  Like I said, I gave up on JWT do to my lack of comprehension of how one might exploit JWT AND the ridiculous/tedious arguments in said threads.

The reason I said DRF is for mobile apps is because when I look at React + DRF websites, they all use this package

I can agree that this project is only suited for mobile apps and not websites.  One of the (presumably) many ways you can use DRF w/o this project is by having django serve the UI.

Regarding a production ready test... I had started implementing JWT in a seed project I use.  It currently shamefully uses localstorage, and I broke the refresh middleware at somepoint... but it could serve as starting point.  I also built this under the assumption that you could set httpOnly cookies form JS (you cant).
Which has lead me to believe that what @fergyfresh is doing... seems to be the way its supposed to be used.

OOOoooof! Ya those are some really compelling and succinct arguments for not using JWT at all.

Correct. I wouldn’t say JWT is completely bad, as it is useful for mobile apps. All companies including Google, Instagram, Facebook, GitHub, etc. use JWT but add the OAuth protocol in addition to it. If you plan on making just a mobile package, this is the one to check out as the protocols for OAuth are pretty similar to the ones set up here. If you do a website with login, you should just stick with sessions and move on. It’s a tried and tested method. Same with OAuth + JWT but not JWT by itself.

Last april Oauth got cracked.

Still missing websocket and image auth when using jwt.
Any suggestions for that? Besides using an image service :-)
Always used (httpOnly) cookie-based tokens because of this

@yoerivdm It depends which websocket you're talking about. For example, the native Django 3.0 websocket (you can check out my configuration at https://github.com/pydanny/cookiecutter-django) would decode method to verify if the token is valid. If you use django channels, then you would use their database_sync_to_async method and do the same validation with the authentication.py.
It would depend heavily on which method you are going for.

@derek-adair When you give developers too much flexibility, you begin to open up several loopholes. Like many many loopholes. Again, this is why I recommend JWT to be only used for mobile clients.

I believe saving jwt in the cookie in the first place was trying solve the problemof making sure user "stays logged in even after page refresh"
Wouldn't it be better to just set

user's session cookie and
Csrf cookie
in the Response along with jwt access & refresh tokens ?

Simply call :
login(request) to automatically create the user session before returning the Response
Then the session & csrf middleware will automatically set both csrf & session cookies with HttpOnly & Same-Site = Lax ( default can be changed )
This way, jwt tokens no longer needs to be saved in cookie in order for user stay logged in after page refresh. User now has the session & csrf cookie with HttpOnly & Same-Site = Lax. This also can resolve both XSS & CSRF attack.
Then whenever user logout....simply create an Api endpoint that will call :
logout(request) function to delete user's session automatically.
Not sure if I'm getting this right ?

@Andrew-Chen-Wang

this is why I recommend JWT to be only used for mobile clients.
In case of single page applications, I have to use JWT.
Are you planning to release this feature any soon ?

@ahmedosama5200 , @davesque said he needed to take a thorough review of it, but his day job keeps him pretty busy. I can't say I have too much to know about SPA security, but we did set up template repositories for some frameworks to get you started with our best knowledge of how SimpleJWT should work in your monorepo:
#263 shows all the JS frameworks we have completed. All you need to do is click on the one you need and press "Use this template". It's not a fork but a copy. It has the entire authentication configuration done for you so you can immediately start working on your SPA.

@Andrew-Chen-Wang I took a look at the react template. It uses localstorage to store jwt tokens which is insecure. Any malicious script can read off localstorage values. The best place to store them is in httponly cookies.
I had a react SPA before. here is how I did it, in case someone needed it.
1=> the client sends authentication info (username & password or oauth2 token). On the server, a jwt is created if user is authenticated. we send them back in the response data for mobile clients and also we set an httponly cookie for the web client.
access_token = str(AccessToken.for_user(user))

res = Response({
    'access_token': access_token
}, status=status_code)
res.set_cookie(ACCESS_TOKEN_COOKIE_NAME, access_token, max_age=settings.SIMPLE_JWT.get(
    'ACCESS_TOKEN_LIFETIME').total_seconds(), secure=not settings.CUSTOM_DEBUG, httponly=True)

return res

for that to work, we need to set CORS_ALLOW_CREDENTIALS = True in settings.py
2=> Whenever the client makes a request, the cookies will be sent by default. in case of using axios, you need to set withCredentials:true.
3=> Now, we need to extend JWTAuthentication backend. It expects the request to have an authorization header. what we will do, is to check if we have a cookie named 'access-token' or whatever we named it, we will set the authorization header manually and let JWTAuthentication do its job.
class CookieHandlerJWTAuthentication(JWTAuthentication):
    def authenticate(self, request):
        # If cookie contains access token, put it inside authorization header
        access_token = request.COOKIES.get(ACCESS_TOKEN_COOKIE_NAME)
        if(access_token):
            request.META['HTTP_AUTHORIZATION'] = '{header_type} {access_token}'.format(
                header_type=settings.SIMPLE_JWT['AUTH_HEADER_TYPES'][0], access_token=access_token)

        return super().authenticate(request)

I am not sure if this is the best way to do this. Also we probably should include a refresh token for more security, I guess.
Please let me know what you think

@ahmedosama5200 A PR is definitely appreciated.
My initial thought after reviewing all these JS template frameworks was just to get something started. I didn't think a simple documentation was enough for most people to implement this safely. Thus, I wanted template repositories to make sure everyone had a safe and secure way of doing all this.
Unfortunately, if you look at the first conversation in JWT-Angular, we had to go with local storage at first. Luckily, loicgasser is currently making changes to incorporate httpOnly cookies. Because I don't have perms to release this package, I can only say take a look at loicgasser's work.

If anything, I think adding a refresh token isn't necessary (instead just use HS512), and I wish this PR would just turn into its own package for the simple reason of "this shouldn't be token authentication." Because, at the end of the day, the purpose of all this is implementing a stateful session backend.

@Andrew-Chen-Wang - I'm inclined to think you're right. With a little redirect trickery in Django, you can happily use session based authentication with an SPA with no problems.
From a dns point of view, you can structure:
api.app.com > django-app
sign-in.app.com > django-app
app.app.com > vue-app / react-app whatever frontend
When a user browses to app.* it checks to see if they have a valid session (via api.app.com/authenticated/). If they aren't authenticated, redirect to sign-in.app.com.
sign-in.app.com renders a template which simply has "window.location.href = app.app.com/login".
Now you have a valid CSFR token and session. You then send the username/password to sign-in.app.com/account/login/ to authenticate the credentials.
The sessionid originally set by the first django-app render now has a valid authenticated user session.
No need for JWTs. You'll notice if you go to many enterprise applications they redirect you all over the place - a some of this is setting server sessions and cookies to avoid storing tokens.

@trentmurray I think an issue with this strategy is localhost testing. I think in production, that should work (if you're setting the session cookie location to be .domain.com), but I worry about local debugging. Additionally, I wouldn't know how that'd do with unittesting with Django's Client class.

Hi, I have been reading through the whole issue without being able to answer this question :
Is it possible to use an HttpOnly cookie to pass an access token to the backend with SimpleJWT ?
Not a refresh token, as it seems to be the issue here, but an access token.
I do not blame anyone, the answer is certainly here, but I am not able find it.

@leogout I think I've come to the conclusion of what people want: currently Django's session middleware is implementing stateful sessions. What people want here is stateless sessions, meaning it's backed by nothing. For both, we encrypt. But the statefulness of sessions middleware is we back it by a cache/database.
If we want stateless sessions, then the only move to do is have a single token. Not necessarily a refresh or access; it's just the amount of time before a generated token is invalid.
So to answer your question directly, yes but why bother?

@Andrew-Chen-Wang My thought exactly. I just went with a simple LocalStorage solution.
It would be equally annoying to allow credentials through CORS and joining token info to the cookie for a JWT and for a stateful session, except stateful cookie based session is safer and lasts longer than a JWT, in session or not.

Hm, local storage is still not safe. Lemme elaborate throughout my learning process here:
To me, stateless authentication is still not safe in the hands of the developers since we're all so bad at following rules and standards and protocols etc. Luckily, the default in this repository is the secret key for your Django application, but if you use a weak algorithm, then you secret key can be leaked.
I've said it before but giving too much flexibility to the developer when it comes to security is not good. For example, since you mentioned localStorage, you're at risk for losing all user's confidence in a XSS scripting attack. httpOnly cookies avoid XSS for authorization details. Even if you've lost to a XSS attack with the cookies, at least they can't deal damage to ALL users' confidentiality/details, only some certain details. Twitter gets a XSS attack a bunch, but people's usernames aren't changed.
I think the localStorage option has been the default for every tutorial. I want to merge one of the two PRs for httpOnly cookies soon just to experiment and watch out for CVEs.

I'm really confused. Should I use session or jwt for react app?
Also i might make a mobile app in the future, so what should i use then?

Sure jwt
On Sun, 6 Dec 2020, 8:20 am RizeXor<EMAIL_ADDRESS>wrote:

I'm really confused. Should I use session or jwt for react app?
Also i might make a mobile app in the future, so what should i use then?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/SimpleJWT/django-rest-framework-simplejwt/issues/71#issuecomment-739462031,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AELSCEYGVWUWVLLBGTAQXPLSTMPBZANCNFSM4GSRP6LA
.

@RizeXor You should use JWT for mobile apps for security reasons (not secure connections, no csrf token, etc.). You don't have cookies to set in transit for mobile apps, so you use JWT.
When it comes to a ReactJS app, the current implementation method would be JWT. There's already a repository set up for you that you can download as a template so that you don't need to set it up yourself. Ref #263

Another workaround for now, add this to urls before urlpatterns = [...]. Using this, TokenRefreshView.as_view() expects a cookie in the request named 'refresh_token'.
# url.py
# ...
from rest_framework_simplejwt.serializers import TokenRefreshSerializer
from rest_framework_simplejwt.exceptions import InvalidToken

class CookieTokenRefreshSerializer(TokenRefreshSerializer):
    refresh = None
    def validate(self, attrs):
        attrs['refresh'] = self.context['request'].COOKIES.get('refresh_token')
        if attrs['refresh']:
            return super().validate(attrs)
        else:
            raise InvalidToken('No valid token found in cookie \'refresh_token\'')
TokenRefreshView.serializer_class = CookieTokenRefreshSerializer

Another workaround for now, add this to urls before urlpatterns = [...]. Using this, TokenRefreshView.as_view() expects a cookie in the request named 'refresh_token'.
# url.py
# ...
from rest_framework_simplejwt.serializers import TokenRefreshSerializer
from rest_framework_simplejwt.exceptions import InvalidToken

class CookieTokenRefreshSerializer(TokenRefreshSerializer):
    refresh = None
    def validate(self, attrs):
        attrs['refresh'] = self.context['request'].COOKIES.get('refresh_token')
        if attrs['refresh']:
            return super().validate(attrs)
        else:
            raise InvalidToken('No valid token found in cookie \'refresh_token\'')
TokenRefreshView.serializer_class = CookieTokenRefreshSerializer

To implement this for now as a workaround, you can do the following.
Add this to views.py:
# views.py
from rest_framework_simplejwt.views import TokenRefreshView, TokenObtainPairView
from rest_framework_simplejwt.serializers import TokenRefreshSerializer
from rest_framework_simplejwt.exceptions import InvalidToken

class CookieTokenRefreshSerializer(TokenRefreshSerializer):
    refresh = None
    def validate(self, attrs):
        attrs['refresh'] = self.context['request'].COOKIES.get('refresh_token')
        if attrs['refresh']:
            return super().validate(attrs)
        else:
            raise InvalidToken('No valid token found in cookie \'refresh_token\'')

class CookieTokenObtainPairView(TokenObtainPairView):
  def finalize_response(self, request, response, *args, **kwargs):
    if response.data.get('refresh'):
        cookie_max_age = 3600 * 24 * 14 # 14 days
        response.set_cookie('refresh_token', response.data['refresh'], max_age=cookie_max_age, httponly=True )
        del response.data['refresh']
    return super().finalize_response(request, response, *args, **kwargs)

class CookieTokenRefreshView(TokenRefreshView):
    def finalize_response(self, request, response, *args, **kwargs):
        if response.data.get('refresh'):
            cookie_max_age = 3600 * 24 * 14 # 14 days
            response.set_cookie('refresh_token', response.data['refresh'], max_age=cookie_max_age, httponly=True )
            del response.data['refresh']
        return super().finalize_response(request, response, *args, **kwargs)
    serializer_class = CookieTokenRefreshSerializer

Change the urls in url.py to use those views for token obtaining and refreshing:
# url.py
from .views import CookieTokenRefreshView, CookieTokenObtainPairView # Import the above views
# [...]
urlpatterns = [
    path('auth/token/', CookieTokenObtainPairView.as_view(), name='token_obtain_pair'),
    path('auth/token/refresh/', CookieTokenRefreshView.as_view(), name='token_refresh'),
    # [...]
]

Workflow - obtain token pair using credentials

POST /auth/token with valid credentials
In the response body you'll notice that only the 'access' key is set
The 'refresh' key has been moved to the httpOnly cookie named 'refresh_token'

Workflow - obtain access token using refresh token

POST /auth/token/refresh with the cookie set from the previous workflow, the body can be empty
In the response body you'll notice that only the 'access' key is set
If you have set ROTATE_REFRESH_TOKENS, the httpOnly cookie 'refresh_token' contains a new refresh token

To implement this for now as a workaround, you can do the following.
Add this to views.py:
# views.py
from rest_framework_simplejwt.views import TokenRefreshView, TokenObtainPairView
from rest_framework_simplejwt.serializers import TokenRefreshSerializer
from rest_framework_simplejwt.exceptions import InvalidToken

class CookieTokenRefreshSerializer(TokenRefreshSerializer):
    refresh = None
    def validate(self, attrs):
        attrs['refresh'] = self.context['request'].COOKIES.get('refresh_token')
        if attrs['refresh']:
            return super().validate(attrs)
        else:
            raise InvalidToken('No valid token found in cookie \'refresh_token\'')

class CookieTokenObtainPairView(TokenObtainPairView):
  def finalize_response(self, request, response, *args, **kwargs):
    if response.data.get('refresh'):
        cookie_max_age = 3600 * 24 * 14 # 14 days
        response.set_cookie('refresh_token', response.data['refresh'], max_age=cookie_max_age, httponly=True )
        del response.data['refresh']
    return super().finalize_response(request, response, *args, **kwargs)

class CookieTokenRefreshView(TokenRefreshView):
    def finalize_response(self, request, response, *args, **kwargs):
        if response.data.get('refresh'):
            cookie_max_age = 3600 * 24 * 14 # 14 days
            response.set_cookie('refresh_token', response.data['refresh'], max_age=cookie_max_age, httponly=True )
            del response.data['refresh']
        return super().finalize_response(request, response, *args, **kwargs)
    serializer_class = CookieTokenRefreshSerializer

Change the urls in url.py to use those views for token obtaining and refreshing:
# url.py
from .views import CookieTokenRefreshView, CookieTokenObtainPairView # Import the above views
# [...]
urlpatterns = [
    path('auth/token/', CookieTokenObtainPairView.as_view(), name='token_obtain_pair'),
    path('auth/token/refresh/', CookieTokenRefreshView.as_view(), name='token_refresh'),
    # [...]
]

Workflow - obtain token pair using credentials

POST /auth/token with valid credentials
In the response body you'll notice that only the 'access' key is set
The 'refresh' key has been moved to the httpOnly cookie named 'refresh_token'

Workflow - obtain access token using refresh token

POST /auth/token/refresh with the cookie set from the previous workflow, the body can be empty
In the response body you'll notice that only the 'access' key is set
If you have set ROTATE_REFRESH_TOKENS, the httpOnly cookie 'refresh_token' contains a new refresh token

Please ref #360 and a specific comment made by stunaz ;)

Please ref #360 and a specific comment made by stunaz ;)

To implement this for now as a workaround, you can do the following.
Add this to views.py:
# views.py
from rest_framework_simplejwt.views import TokenRefreshView, TokenObtainPairView
from rest_framework_simplejwt.serializers import TokenRefreshSerializer
from rest_framework_simplejwt.exceptions import InvalidToken

class CookieTokenRefreshSerializer(TokenRefreshSerializer):
    refresh = None
    def validate(self, attrs):
        attrs['refresh'] = self.context['request'].COOKIES.get('refresh_token')
        if attrs['refresh']:
            return super().validate(attrs)
        else:
            raise InvalidToken('No valid token found in cookie \'refresh_token\'')

class CookieTokenObtainPairView(TokenObtainPairView):
  def finalize_response(self, request, response, *args, **kwargs):
    if response.data.get('refresh'):
        cookie_max_age = 3600 * 24 * 14 # 14 days
        response.set_cookie('refresh_token', response.data['refresh'], max_age=cookie_max_age, httponly=True )
        del response.data['refresh']
    return super().finalize_response(request, response, *args, **kwargs)

class CookieTokenRefreshView(TokenRefreshView):
    def finalize_response(self, request, response, *args, **kwargs):
        if response.data.get('refresh'):
            cookie_max_age = 3600 * 24 * 14 # 14 days
            response.set_cookie('refresh_token', response.data['refresh'], max_age=cookie_max_age, httponly=True )
            del response.data['refresh']
        return super().finalize_response(request, response, *args, **kwargs)
    serializer_class = CookieTokenRefreshSerializer

Change the urls in url.py to use those views for token obtaining and refreshing:
# url.py
from .views import CookieTokenRefreshView, CookieTokenObtainPairView # Import the above views
# [...]
urlpatterns = [
    path('auth/token/', CookieTokenObtainPairView.as_view(), name='token_obtain_pair'),
    path('auth/token/refresh/', CookieTokenRefreshView.as_view(), name='token_refresh'),
    # [...]
]

Check your CORS settings if it doesn't work as expected: maybe you have to set sameSite and secure in set_cookie
Workflow - obtain token pair using credentials

POST /auth/token with valid credentials
In the response body you'll notice that only the 'access' key is set
The 'refresh' key has been moved to the httpOnly cookie named 'refresh_token'

Workflow - obtain access (and optional refresh) token using refresh token

POST /auth/token/refresh with the cookie set from the previous workflow, the body can be empty
In the response body you'll notice that only the 'access' key is set
If you have set ROTATE_REFRESH_TOKENS, the httpOnly cookie 'refresh_token' contains a new refresh token

I think you should override CookieTokenRefreshView's serializer with CookieTokenRefreshSerializer.

To implement this for now as a workaround, you can do the following.
Add this to views.py:
# views.py
from rest_framework_simplejwt.views import TokenRefreshView, TokenObtainPairView
from rest_framework_simplejwt.serializers import TokenRefreshSerializer
from rest_framework_simplejwt.exceptions import InvalidToken

class CookieTokenRefreshSerializer(TokenRefreshSerializer):
    refresh = None
    def validate(self, attrs):
        attrs['refresh'] = self.context['request'].COOKIES.get('refresh_token')
        if attrs['refresh']:
            return super().validate(attrs)
        else:
            raise InvalidToken('No valid token found in cookie \'refresh_token\'')

class CookieTokenObtainPairView(TokenObtainPairView):
  def finalize_response(self, request, response, *args, **kwargs):
    if response.data.get('refresh'):
        cookie_max_age = 3600 * 24 * 14 # 14 days
        response.set_cookie('refresh_token', response.data['refresh'], max_age=cookie_max_age, httponly=True )
        del response.data['refresh']
    return super().finalize_response(request, response, *args, **kwargs)

class CookieTokenRefreshView(TokenRefreshView):
    def finalize_response(self, request, response, *args, **kwargs):
        if response.data.get('refresh'):
            cookie_max_age = 3600 * 24 * 14 # 14 days
            response.set_cookie('refresh_token', response.data['refresh'], max_age=cookie_max_age, httponly=True )
            del response.data['refresh']
        return super().finalize_response(request, response, *args, **kwargs)
    serializer_class = CookieTokenRefreshSerializer

Change the urls in url.py to use those views for token obtaining and refreshing:
# url.py
from .views import CookieTokenRefreshView, CookieTokenObtainPairView # Import the above views
# [...]
urlpatterns = [
    path('auth/token/', CookieTokenObtainPairView.as_view(), name='token_obtain_pair'),
    path('auth/token/refresh/', CookieTokenRefreshView.as_view(), name='token_refresh'),
    # [...]
]

Check your CORS settings if it doesn't work as expected: maybe you have to set sameSite and secure in set_cookie
Workflow - obtain token pair using credentials

POST /auth/token with valid credentials
In the response body you'll notice that only the 'access' key is set
The 'refresh' key has been moved to the httpOnly cookie named 'refresh_token'

Workflow - obtain access (and optional refresh) token using refresh token

POST /auth/token/refresh with the cookie set from the previous workflow, the body can be empty
In the response body you'll notice that only the 'access' key is set
If you have set ROTATE_REFRESH_TOKENS, the httpOnly cookie 'refresh_token' contains a new refresh token

This looks well and good but is the CSRF token not necessary for methods like POST, PUT?
here is an implementation of JWT + CSRF token + Cookies (HttpOnly) LocalStorage vs Cookies: All You Need To Know About Storing JWT Tokens Securely in The Front-End

so anyone where is solution for implementation http only? still no finding in docs

@davesque Besides the refresh-token via cookie being more secure there is another important point. Jwt usecase is as follows: an authorization service + regular services. The former issues tokens, the latter use access tokens. What if there is multiple regular services and they belong to the same organization? And that organization doesn't want to ask the user to log-in multiple times?
So you have to pass the refresh token to every client (for every "regular service" that you have). And require the user to log-in multiple times. Which could be solved otherwise by setting a cookie for the auth service.

any update on this ?

any update on this? thanks.

Are you kidding me?! After about four years, this critical feature has not been added?!
So what's the point of this whole JWT shit?!

To implement this for now as a workaround, you can do the following.
Add this to views.py:
# views.py
from rest_framework_simplejwt.views import TokenRefreshView, TokenObtainPairView
from rest_framework_simplejwt.serializers import TokenRefreshSerializer
from rest_framework_simplejwt.exceptions import InvalidToken

class CookieTokenRefreshSerializer(TokenRefreshSerializer):
    refresh = None
    def validate(self, attrs):
        attrs['refresh'] = self.context['request'].COOKIES.get('refresh_token')
        if attrs['refresh']:
            return super().validate(attrs)
        else:
            raise InvalidToken('No valid token found in cookie \'refresh_token\'')

class CookieTokenObtainPairView(TokenObtainPairView):
  def finalize_response(self, request, response, *args, **kwargs):
    if response.data.get('refresh'):
        cookie_max_age = 3600 * 24 * 14 # 14 days
        response.set_cookie('refresh_token', response.data['refresh'], max_age=cookie_max_age, httponly=True )
        del response.data['refresh']
    return super().finalize_response(request, response, *args, **kwargs)

class CookieTokenRefreshView(TokenRefreshView):
    def finalize_response(self, request, response, *args, **kwargs):
        if response.data.get('refresh'):
            cookie_max_age = 3600 * 24 * 14 # 14 days
            response.set_cookie('refresh_token', response.data['refresh'], max_age=cookie_max_age, httponly=True )
            del response.data['refresh']
        return super().finalize_response(request, response, *args, **kwargs)
    serializer_class = CookieTokenRefreshSerializer

Change the urls in url.py to use those views for token obtaining and refreshing:
# url.py
from .views import CookieTokenRefreshView, CookieTokenObtainPairView # Import the above views
# [...]
urlpatterns = [
    path('auth/token/', CookieTokenObtainPairView.as_view(), name='token_obtain_pair'),
    path('auth/token/refresh/', CookieTokenRefreshView.as_view(), name='token_refresh'),
    # [...]
]

Check your CORS settings if it doesn't work as expected: maybe you have to set sameSite and secure in set_cookie
Workflow - obtain token pair using credentials

POST /auth/token with valid credentials
In the response body you'll notice that only the 'access' key is set
The 'refresh' key has been moved to the httpOnly cookie named 'refresh_token'

Workflow - obtain access (and optional refresh) token using refresh token

POST /auth/token/refresh with the cookie set from the previous workflow, the body can be empty
In the response body you'll notice that only the 'access' key is set
If you have set ROTATE_REFRESH_TOKENS, the httpOnly cookie 'refresh_token' contains a new refresh token

Refer to this

It's been years. Any update?

any update on this? thanks.


Validate cloud init/cloud config

This is essential for CoreOS clusters.

Silly me, we already accept userData. I'll change the title here to be about validation.

I think this logic should reside in Gophercloud. I'll label it as such, and you can remove it if that's not the case.

Yeah, that's a good higher order thing to add to Gophercloud.

per @jrperritt this is non-trivial, and while we should totally do this, it's not going to happen for public beta.

Fine by me.


Compilations performed to instantiate lazy constants aren't cached

This compilation isn't cached anywhere, so code like the following:
big_lazy_x = jnp.ones((jax.device_count(), 1e6))
for _ in range(100):
  _ = pmap(lambda x: x)(big_lazy_x)

will result in one compilation per device per step of the function that instantiates big_lazy_x.
This should be fixed by the new lazy infra (#1668).

By the way, that link into the code may have bitrotted, in that I don't think it's pointing to the right place anymore. (What I do to make a link is select a line and then press 'y' in GitHub's web interface to get a pointer to a specific commit. Those don't rot!)
I'm pretty sure it used to point to _instantiate_device_constant, which indeed isn't cached. And indeed #1668 fixes this! I'll add a test to that PR...


[Feature Request] Merge similar orders

Is there an existing issue for this?

[X] I have searched the existing issues

Is your feature request related to a problem? Please describe.
About the problem:

There is a limit of 500 sell orders, you can't have more
More orders means slow response
You must pay reg fees for every sale order
You get unnecessary errors with api call

Describe the solution you'd like.
For example:
We have 3 separated orders to sell AAPL at $170.02
Sell Order1:
Symbol: APPL
Qty: 1
Limit Price: 172.02
Sell Order2:
Symbol: APPL
Qty: 5
Limit Price: 172.02
Sell Order3:
Symbol: APPL
Qty: 3
Limit Price: 172.02
We need a feature to be able to convert those 3 orders in just 1 order.
The results will be something like this:
Unique Sell Order:
Symbol: APPL
Qty: 9
Limit Price: 172.02
This new feature will help us to:

Reduce the amount of open orders
Reduce the time spent querying open orders
Reduce regulatory fees
Avoid unnecessary errors with api call

Describe an alternate solution.
Occam's razor | keep it simple
Anything else? (Additional Context)
Occam's razor | keep it simple

Someone from Alpaca team has suggested a method in the py package.

The suggestion was for implement it, is not available yet.


split pane "splitMode:duplicate" not working.

Environment
Windows build number: Microsoft Windows [Version 10.0.19042.546]
Windows Terminal version: 1.3.2651.0

Any other software?
zsh (powerlevel10k) is my default shell

Steps to reproduce

Configuration in terminal setting for
"keybindings": [
    { "command": "copy", "keys": ["ctrl+shift+c"] },
    { "command": "paste", "keys": ["ctrl+shift+v"] },
    {
      "command": {
        "action": "splitPane",
        "split": "auto",
        "splitMode": "duplicate"
      },
      "keys": "alt+shift+d"
    },
    {
      "command": {
        "action": "splitPane",
        "split": "vertical",
        "splitMode": "duplicate"
      },
      "keys": "alt+shift+="
    },
    {
      "command": {
        "action": "splitPane",
        "split": "horizontal",
        "splitMode": "duplicate"
      },
      "keys": "alt+shift+-"
    }
  ]

Expected behavior

On using commands - alt+shift+d or alt+shift+= or alt+shift+- expected to duplicate my current pane path in the new split pane.
Actual behavior
In new split pane i'm getting the home(~) path.

/dup #3158


account with zero balance showing as negative

may be solved by #285

@ezra-sg can you check if this has been resolved? if so, close.

resolved


Vitest - Error when running tests - TypeError: Cannot read properties of undefined (reading 'x')

What platform were you using when you found the bug?

React Flow / Svelte Flow version: 12.3.4
Browser and version: Chrome (latest) --- (130.0.6723.117 (Official Build) (arm64))
OS and version: MacOS 14.7.1

Live code example
No response
Describe the Bug
When running my unit tests (they pass, technically) they are reporting errors in the xyflow stuff.
Steps to reproduce the bug or issue
Running Vitest (latest) and react-vite and vite (all latest)
I am using a custom Node inside of my ReactFlow. Then i am also creating a custom component to contain my react flow component inside of. Then i put that component inside of whatever parent is supposed to consume it.
one of my tests may look something like this:
test("If the component renders", () => {
    const { container } = render(
      <ReactFlowProvider>
        <MyContainer
          onBackButtonClick={mockOnBackButtonClick}
          myData={mockData}
          activeItem={mockActiveItem}
          setActiveItem={mockSetActiveItem}
        />
      </ReactFlowProvider>,
    );
    expect(container).toBeTruthy();
  });

Expected behavior
I would expect the tests to pass (which they technically do, but throwing these errors)
Screenshots or Videos
I cannot seem to paste into github due to a company proxy block, but the error is pasted below
Additional context
TypeError: Cannot read properties of undefined (reading 'x')
 ❯ getNodePositionWithOrigin node_modules/@xyflow/system/dist/esm/index.js:193:26
    193| };
    194| /**
    195|  * Internal function for determining a bounding box that contains all given nodes in an array.
       |                   ^
    196|  * @public
    197|  * @remarks Useful when combined with {@link getViewportForBounds} to calculate the correct transform to fit the given nodes in a viewport.
 ❯ Module.adoptUserNodes node_modules/@xyflow/system/dist/esm/index.js:1235:40
 ❯ setNodes node_modules/@xyflow/react/dist/esm/index.js:2742:31
 ❯ node_modules/@xyflow/react/dist/esm/index.js:263:17
 ❯ commitHookEffectListMount node_modules/react-dom/cjs/react-dom.development.js:23189:26
 ❯ commitPassiveMountOnFiber node_modules/react-dom/cjs/react-dom.development.js:24970:11
 ❯ commitPassiveMountEffects_complete node_modules/react-dom/cjs/react-dom.development.js:24930:9
 ❯ commitPassiveMountEffects_begin node_modules/react-dom/cjs/react-dom.development.js:24917:7
 ❯ commitPassiveMountEffects node_modules/react-dom/cjs/react-dom.development.js:24905:3
 ❯ flushPassiveEffectsImpl node_modules/react-dom/cjs/react-dom.development.js:27078:3

This is too little information to go by. The only thing I can read out from this is that you are passing nodes that don't have a position.x.


Add support for command JSON.ARRINSERT

Add support for the JSON.ARRINSERT command in DiceDB similar to the JSON.ARRINSERT command in Redis. Please refer to the following commit in Redis to understand the implementation specifics - source.
Write unit and integration tests for the command referring to the tests written in the Redis codebase 7.2.5. For integration tests, you can refer to the tests folder. Note: they have used TCL for the test suite, and we need to port that to our way of writing integration tests using the relevant helper methods. Please refer to our tests directory.
For the command, benchmark the code and measure the time taken and memory allocs using benchmem and try to keep them to the bare minimum.

@jujiale since you've extensively helped support JSON features in DiceDB so far, would you like to take this issue up?

@jujiale since you've extensively helped support JSON features in DiceDB so far, would you like to take this issue up?

sure.please assgin to me. thanks.

Hello @lucifercr07 & @jujiale ,
Is this still being worked upon ? Otherwise I'll be happy to pick this up.
Thanks

Hello @lucifercr07 & @jujiale , Is this still being worked upon ? Otherwise I'll be happy to pick this up. Thanks

yes. processing.


Add dingda-adfree to cooperation

Add dingda-adfree to cooperation

Same to need add to README-zh-CN.md

Added.