Rescue TypeError if a top-level class named Behavior exists

If your application defines a top-level class named Behavior, loading
rspec/rails/example/request_example_group.rb with Rails <IP_ADDRESS>
results in a compiler warning:
warning: toplevel constant Behavior referenced by ActionDispatch::IntegrationTest::Behavior
This warning is the result of the situation descibed in https://github.com/rails/rails/issues/6931,
i.e. Rails auto-load magic concludes that the constant named Behavior is already
defined, and tries to use it instead of attempting to auto-load a properly namespaced one.
The result is a TypeError, which can safely be swallowed.

Er no, this can't be safely swallowed, as the wrong module is now included in ActionDispatch::IntegrationTest::Behavior, they need to fix this by properly referencing the constant to fix the autoload.

Please open an issue with the rails team about this.

It could be safely swallowed if ::Behavior is a class, but not if it's a module.  In the short term, merging this would have unblocked my team and others who have a class Behavior.

Rails team can't fix this.  As the issue I linked explains, they've escalated it to the Ruby core team, who is considering fixing it for Ruby 2.4.0.

The problem can be fixed in rspec-rails by not using an exception for flow control:
if ActionPack::VERSION::MAJOR >= 5
include ActionDispatch::IntegrationTest::Behavior
end

If I address it this way, will you accept the PR?

If ::Behavior is a class, include Behavior will raise a TypeError, which can be swallowed safely. Merging this would have resolved that case and unblocked my team and others who have a class Behavior. If ::Behavior is a module, then, as @JonRowe pointed out, "the wrong module is now included", but that behavior is unchanged in this PR. Thus, the TypeError can be swallowed safely.

No it can't because the module behaviour is now not included, Ruby cannot have both a class and a module with the same name, if an error occurs expected functionality has not occured.

Rails team can't fix this. As the issue I linked explains, they've escalated it to the Ruby core team, who is considering fixing it for Ruby 2.4.0.

They can they can load there module properly by fully qualifying it or swallowing the exception themselves if they think it's safe, this is not a general solution but it will fix this particular case.

The problem can be fixed in rspec-rails by not using an exception for flow control:

include ActionDispatch::IntegrationTest::Behavior
end```
This won't fix it.

If I address it this way, will you accept the PR?

No, this should be addressed upstream, we are referencing a full qualified constant and it is producing a error based on its internals, those internals should be fixed.

No it can't because the module behaviour is now not included, Ruby cannot have both a class and a module with the same name, if an error occurs expected functionality has not occured.

What module behavior?  In Rails 3 and 4, there is no such module.
In Rail 5, ActionDispatch::IntegrationTest is explicitly auto-loaded here, so require 'action_dispatch' should be enough to make sure the right module is included, and that's already happening as soon as you require 'rails'.  The rails issue I mentioned above only occurs when the class you are trying to auto-load can be found in an autoload_path, not when it's explicitly auto-loaded.

The problem can be fixed in rspec-rails by not using an exception for flow control:

Shouldn't this be a good enough reason to fix it here even upstream changes would make it behave differently?

if ActionPack::VERSION::MAJOR >= 5
This won't fix it.

I must really be missing something here.  If rspec-rails can safely swallow a NameError, that means that in Rails 3 and 4, it doesn't need this module.  So why won't this fix it?
I made a mistake by linking to the Rails issue.  I thought that would help by making it unnecessary to repeat what was already stated there, but it seems that instead it just gave the false impression that this is not a flaw in rspec-rails.

Using exceptions for flow control is generally a bad idea, so I'd definitely be in favor of doing a version check instead of attempting inclusion with a rescue fallback.

@betesh if you want to convert the check to an if go ahead, but it won't fix any errors caused by Behaviour being misloaded.

@betesh if you want to convert the check to an if go ahead, but it won't fix any errors caused by Behaviour being misloaded.

But it'll make rspec-rails avoid trying to load ActionDispatch::IntegrationTest::Behavior on rails versions that do not define that module.  And, from what I understand about ruby constant resolution, on applications that define a Behavior class, it'll work properly on rails versions that do provide that module.  Ruby constant resolution provides top-level constants when the fully qualified nested constant does not exist -- so if Behavior is returned from a ActionDispatch::IntegrationTest::Behavior reference only when ActionDispatch::IntegrationTest::Behavior does not exist.

Done.  See #1660
Would it be possible to release this as v3.5.1, compatible with rspec v3.5.0?


06-cascade-fix: Add a punctation mark

Because
Line 88 was missing a comma.
This PR

Add a comma.

Pull Request Requirements

[x] I have thoroughly read and understand The Odin Project Contributing Guide
[x] The title of this PR follows the location of change: brief description of change format, e.g. 01-flex-center: Update self check
[x] The Because section summarizes the reason for this PR
[x] The This PR section has a bullet point list describing the changes in this PR
[x] If this PR addresses an open issue, it is linked in the Issue section
[x] If applicable, I have ensured that the TOP solution files match the Desired Outcome image

Thanks for contributing @Evergard


[bug?] Failed to script mask-rcnn model

Hi, when I try to script the model I get the following traceback (pytorch 1.4.0, torchvision 0.5.0):
Traceback (most recent call last):
  File "to_torchscript_model.py", line 34, in <module>
    main(sys.argv[1])
  File "to_torchscript_model.py", line 21, in main
    script_module = torch.jit.script(model)
  File "/home/bruno/.local/lib/python3.6/site-packages/torch/jit/__init__.py", line 1255, in script
    return torch.jit._recursive.recursive_script(obj)
  File "/home/bruno/.local/lib/python3.6/site-packages/torch/jit/_recursive.py", line 534, in recursive_script
    return create_script_module(nn_module, infer_methods_to_compile(nn_module))
  File "/home/bruno/.local/lib/python3.6/site-packages/torch/jit/_recursive.py", line 296, in create_script_module
    return create_script_module_impl(nn_module, concrete_type, cpp_module, stubs)
  File "/home/bruno/.local/lib/python3.6/site-packages/torch/jit/_recursive.py", line 336, in create_script_module_impl
    script_module = torch.jit.RecursiveScriptModule._construct(cpp_module, init_fn)
  File "/home/bruno/.local/lib/python3.6/site-packages/torch/jit/__init__.py", line 1593, in _construct
    init_fn(script_module)
  File "/home/bruno/.local/lib/python3.6/site-packages/torch/jit/_recursive.py", line 328, in init_fn
    scripted = recursive_script(orig_value)
  File "/home/bruno/.local/lib/python3.6/site-packages/torch/jit/_recursive.py", line 534, in recursive_script
    return create_script_module(nn_module, infer_methods_to_compile(nn_module))
  File "/home/bruno/.local/lib/python3.6/site-packages/torch/jit/_recursive.py", line 296, in create_script_module
    return create_script_module_impl(nn_module, concrete_type, cpp_module, stubs)
  File "/home/bruno/.local/lib/python3.6/site-packages/torch/jit/_recursive.py", line 340, in create_script_module_impl
    create_methods_from_stubs(concrete_type, stubs)
  File "/home/bruno/.local/lib/python3.6/site-packages/torch/jit/_recursive.py", line 259, in create_methods_from_stubs
    concrete_type._create_methods(defs, rcbs, defaults)
  File "/home/bruno/.local/lib/python3.6/site-packages/torch/jit/_recursive.py", line 574, in compile_unbound_method
    create_methods_from_stubs(concrete_type, (stub,))
  File "/home/bruno/.local/lib/python3.6/site-packages/torch/jit/_recursive.py", line 259, in create_methods_from_stubs
    concrete_type._create_methods(defs, rcbs, defaults)
  File "/home/bruno/.local/lib/python3.6/site-packages/torch/jit/_recursive.py", line 555, in try_compile_fn
    return torch.jit.script(fn, _rcb=rcb)
  File "/home/bruno/.local/lib/python3.6/site-packages/torch/jit/__init__.py", line 1281, in script
    fn = torch._C._jit_script_compile(qualified_name, ast, _rcb, get_default_args(obj))
  File "/home/bruno/.local/lib/python3.6/site-packages/torch/jit/_recursive.py", line 555, in try_compile_fn
    return torch.jit.script(fn, _rcb=rcb)
  File "/home/bruno/.local/lib/python3.6/site-packages/torch/jit/__init__.py", line 1281, in script
    fn = torch._C._jit_script_compile(qualified_name, ast, _rcb, get_default_args(obj))
RuntimeError:
object has no attribute _new_empty_tensor_op:
  File "/home/bruno/.local/lib/python3.6/site-packages/torchvision/ops/new_empty_tensor.py", line 16
        output (Tensor)
    """
    return torch.ops.torchvision._new_empty_tensor_op(x, shape)
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <--- HERE
'_new_empty_tensor' is being compiled since it was called from 'interpolate'
  File "/home/bruno/.local/lib/python3.6/site-packages/torchvision/ops/misc.py", line 116
    output_shape = _output_size(2, input, size, scale_factor)
    output_shape = input.shape[:-2] + output_shape
    return _new_empty_tensor(input, output_shape)
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <--- HERE
'interpolate' is being compiled since it was called from 'GeneralizedRCNNTransform.resize'
  File "/home/bruno/.local/lib/python3.6/site-packages/torchvision/models/detection/transform.py", line 104
        if "masks" in target:
            mask = target["masks"]
            mask = misc_nn_ops.interpolate(mask[None].float(), scale_factor=scale_factor)[0].byte()
            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <--- HERE
            target["masks"] = mask
'GeneralizedRCNNTransform.resize' is being compiled since it was called from 'GeneralizedRCNNTransform.forward'
  File "/home/bruno/.local/lib/python3.6/site-packages/torchvision/models/detection/transform.py", line 47
                                 "of shape [C, H, W], got {}".format(image.shape))
            image = self.normalize(image)
            image, target_index = self.resize(image, target_index)
            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <--- HERE
            images[i] = image
            if targets is not None and target_index is not None:

Not sure if this is helpful, but trying to script it a second time instead results in the following:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/bruno/.local/lib/python3.6/site-packages/torch/jit/__init__.py", line 1255, in script
    return torch.jit._recursive.recursive_script(obj)
  File "/home/bruno/.local/lib/python3.6/site-packages/torch/jit/_recursive.py", line 534, in recursive_script
    return create_script_module(nn_module, infer_methods_to_compile(nn_module))
  File "/home/bruno/.local/lib/python3.6/site-packages/torch/jit/_recursive.py", line 296, in create_script_module
    return create_script_module_impl(nn_module, concrete_type, cpp_module, stubs)
  File "/home/bruno/.local/lib/python3.6/site-packages/torch/jit/_recursive.py", line 336, in create_script_module_impl
    script_module = torch.jit.RecursiveScriptModule._construct(cpp_module, init_fn)
  File "/home/bruno/.local/lib/python3.6/site-packages/torch/jit/__init__.py", line 1593, in _construct
    init_fn(script_module)
  File "/home/bruno/.local/lib/python3.6/site-packages/torch/jit/_recursive.py", line 328, in init_fn
    scripted = recursive_script(orig_value)
  File "/home/bruno/.local/lib/python3.6/site-packages/torch/jit/_recursive.py", line 534, in recursive_script
    return create_script_module(nn_module, infer_methods_to_compile(nn_module))
  File "/home/bruno/.local/lib/python3.6/site-packages/torch/jit/_recursive.py", line 296, in create_script_module
    return create_script_module_impl(nn_module, concrete_type, cpp_module, stubs)
  File "/home/bruno/.local/lib/python3.6/site-packages/torch/jit/_recursive.py", line 340, in create_script_module_impl
    create_methods_from_stubs(concrete_type, stubs)
  File "/home/bruno/.local/lib/python3.6/site-packages/torch/jit/_recursive.py", line 259, in create_methods_from_stubs
    concrete_type._create_methods(defs, rcbs, defaults)
RuntimeError: Can't redefine method: forward on class: __torch__.torchvision.models.detection.transform.GeneralizedRCNNTransform (addMethod at /pytorch/torch/csrc/jit/script/class_type.cpp:73)
frame #0: c10::Error::Error(c10::SourceLocation, std::string const&) + 0x33 (0x7fe0b134d193 in /home/bruno/.local/lib/python3.6/site-packages/torch/lib/libc10.so)
frame #1: c10::ClassType::addMethod(torch::jit::Function*) + 0x1d9 (0x7fe0b5c82b29 in /home/bruno/.local/lib/python3.6/site-packages/torch/lib/libtorch.so)
frame #2: torch::jit::script::CompilationUnit::define(c10::optional<c10::QualifiedName> const&, torch::jit::script::Def const&, std::shared_ptr<torch::jit::script::Resolver> const&, torch::jit::script::Self const*, std::unordered_map<std::string, torch::jit::Function*, std::hash<std::string>, std::equal_to<std::string>, std::allocator<std::pair<std::string const, torch::jit::Function*> > > const&, bool) const + 0x6d7 (0x7fe0b5c0fb07 in /home/bruno/.local/lib/python3.6/site-packages/torch/lib/libtorch.so)
frame #3: torch::jit::script::CompilationUnit::define(c10::optional<c10::QualifiedName> const&, std::vector<torch::jit::script::Def, std::allocator<torch::jit::script::Def> > const&, std::vector<std::shared_ptr<torch::jit::script::Resolver>, std::allocator<std::shared_ptr<torch::jit::script::Resolver> > > const&, torch::jit::script::Self const*, bool) + 0x17d (0x7fe0b5c1024d in /home/bruno/.local/lib/python3.6/site-packages/torch/lib/libtorch.so)
frame #4: <unknown function> + 0x77b5e7 (0x7fe1108975e7 in /home/bruno/.local/lib/python3.6/site-packages/torch/lib/libtorch_python.so)
frame #5: <unknown function> + 0x2961c4 (0x7fe1103b21c4 in /home/bruno/.local/lib/python3.6/site-packages/torch/lib/libtorch_python.so)
<omitting python frames>

Sorry for the delay, here's the output:
PyTorch version: 1.4.0
Is debug build: No
CUDA used to build PyTorch: 10.1

OS: Ubuntu 18.04.3 LTS
GCC version: (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
CMake version: version 3.15.20190924-gdcc117b

Python version: 3.6
Is CUDA available: Yes
CUDA runtime version: 10.1.243
GPU models and configuration: GPU 0: GeForce GTX 1060 6GB
Nvidia driver version: 435.21
cuDNN version: /usr/lib/x86_64-linux-gnu/libcudnn.so.7.6.5

Versions of relevant libraries:
[pip3] numpy==1.18.1
[pip3] torch==1.4.0
[pip3] torchvision==0.5.0
[conda] Could not collect

This is weird, can you share a minimum script that reproduces the issue on your side?
My guess is that your torchvision installation is corrupted, and it is not picking the right binary file.

This got fixed after I upgraded my cpu. The earlier cpu didn't support AVX, so I would assume the problem was with AVX support. I am not sure this is worth investigating further as it seems I was the only one hitting the issue, so I am going to close this.

@analyticsbot torch.ops.torchvision._new_empty_tensor_op has been removed from torchvision, as it's an internal implementation detail which is not needed anymore.
If the underlying function using it was interpolate from torchvision, you can now use torch.nn.functional.interpolate instead


question: Book print or pdf version?

I think is good to have a print or pdf version like mdbook does.

See #1070. I agree that this would be a useful feature! There is already a prototype implementation in https://github.com/phil-opp/blog_os/pull/1232, maybe this works for you?

like mdbook does.

Could you post a link to some documentation of this feature? Maybe we can reuse some of its implementation.


cli expects version flag to be in caps

Steps to reproduce
1> composer -v
Expected Behaviour
To display version
Actual Behaviour
cli is expecting version flag to be in caps but usually flags in other cli tools also have been in small case only

As discussed -V will always be in caps in Rust but added --version flag as per standard. So hence closing this issue


Use something like bookdown?

Sorry I'm creeping on your notes but I think they're super nicely done! Congrats!
I think you could, however, add another level of production value if you used something like bookdown or just mkdocs.
Anyway, feel free to take it or leave it. I have a mkdocs for my notes, which links to papers and has zotero integration and is wholly doing the most (if only I spent as much time writing as optimizing my workflow right), and I love it. Jus thought I'd spread the good word.

Haha thank you! It mostly helps me organize my own thoughts, but they're public in case they happen to help anyone else out as well :)
I appreciate the suggestion! I've been meaning to upgrade the medium of the glossary since GH markdown can be quite a pain so I'll definitely keep these in mind for once I finally get around to that :P
I'd also be curious to see your notes workflow -- is it in a public repo somewhere?

I do not, since I have papers and preprints checked into source control. I'm big on mkdocs though here's  some semi-public examples I have:

https://baltimoreblacktechies.github.io/100daysOfCode-2021/
https://dmadisetti.github.io/pd3
https://dmadisetti.github.io/drt

closed by 87c460682eb930ccf1a205c3eee8d68195a9a863

Wow @nglaeser it looks amaazing

Thank you!! :)


Add references section

I found it hard to figure out what is what with sagepay docs so I thought it
made sense to start putting the more useful links in the readme.

Thanks. The link to the second PDF has gone, so I have linked to its replacement HTML page instead. Also added a new TOC generated by VSCode and automatically updated on save.


test: add benchmarks and benchmark helper functions

What type of PR is this?
/kind test
What this PR does / why we need it:
This PR adds benchmarking helper functions to cse_helpers.sh and then utilizes them in pre / post / install-dependencies scripts.  These can be used to view benchmarking data while running ADO pipelines, and can be reviewed during the build or after.
This data will later be used to programmatically evaluate the effect of a PRs code changes on the VHD Build Time.
Which issue(s) this PR fixes:
This code prevents the developer from not being able to easily evaluate how long certain parts of the VHD Build process take.
Requirements:

[ ] uses conventional commit messages
[ ] includes documentation
[ ] adds unit tests
[ ] tested upgrade from previous version

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 79.39%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
2292

Relevant Lines:
2887

💛  - Coveralls


[firebase_messaging]: Have an error when listen messaging when open web

Is there an existing issue for this?

[X] I have searched the existing issues.

Which plugins are affected?
Messaging
Which platforms are affected?
Web
Description
When I push a notification have an error with message:
Instance of 'LinkedMap<Object?, Object?>': type 'LinkedMap<Object?, Object?>' is not a subtype of type 'Map<String, dynamic>?'
I run example https://github.com/firebase/flutterfire/tree/master/packages/firebase_messaging/firebase_messaging same error. Please check it for me

Reproducing the issue

I run example firebase_messaging
Change setup firebase with my project
Push notification when open web and show error above
Please check it for me. Thanks

Firebase Core version
2.20.0
Flutter Version
3.19.3
Relevant Log Output
errors.dart:297 Uncaught (in promise) Error: TypeError: Instance of 'LinkedMap<Object?, Object?>': type 'LinkedMap<Object?, Object?>' is not a subtype of type 'Map<String, dynamic>?'
    at Object.throw_ [as throw] (errors.dart:297:3)
    at Object._failedAsCheck (rti.dart:1385:3)
    at dart_rti.Rti.new._generalNullableAsCheckImplementation (rti.dart:1375:3)
    at get data (messaging.dart:124:31)
    at Object.messagePayloadToMap (utils.dart:50:21)
    at firebase_messaging_web.dart:35:41
    at _RootZone.runUnaryGuarded (zone.dart:1594:9)
    at [_sendData] (stream_impl.dart:339:5)
    at [_add] (stream_impl.dart:271:7)
    at [_sendData] (broadcast_stream_controller.dart:377:24)
    at _SyncBroadcastStreamController.new.add (broadcast_stream_controller.dart:244:5)
    at messaging.dart:83:20
    at Object._checkAndCall (operations.dart:550:37)
    at Object.dcall (operations.dart:555:39)
    at Object.ret [as next] (js_allow_interop_patch.dart:17:11)
    at messageEventListener (window-listener.ts:51:39)

Flutter dependencies

Expand Flutter dependencies snippet

Replace this line with the contents of your `flutter pub deps -- --style=compact`.

Additional context and comments
No response

Thank you @saunptit97, I can replicate it.

Hello, how to update this? Is it already available?

@TarekkMA  Please tell me when It available

It will be available in the next release.

Hello,
When is the next release available ? Because it still doesn't work on 2.28.0

It would be avialbe next week, but until then you can use git references in your pubspec.yaml
https://dart.dev/tools/pub/dependencies#git-packages

When
  firebase_core: ^2.22.0
  firebase_analytics: ^10.8.9
  firebase_crashlytics: ^3.4.18
  firebase_messaging: ^14.7.19
  firebase_performance: ^0.9.3+8
  firebase_app_check: ^0.2.1+17
  firebase_messaging_web:
    git:
      url: https://github.com/firebase/flutterfire.git
      ref: master
      path: packages/firebase_messaging/firebase_messaging_web

Because firebase_messaging >=14.7.19 <14.7.20 depends on firebase_messaging_web ^3.6.8 and firebase_messaging >=14.7.20 <14.7.21 depends on firebase_messaging_web ^3.7.0, firebase_messaging >=14.7.19 <14.7.21 requires firebase_messaging_web ^3.6.8.
And because firebase_messaging >=14.7.21 <14.8.0 depends on firebase_messaging_web ^3.7.1 and firebase_messaging >=14.8.0 depends on firebase_messaging_web ^3.8.0, firebase_messaging >=14.7.19 requires firebase_messaging_web from hosted.
So, because yumi depends on both firebase_messaging ^14.7.19 and firebase_messaging_web from git, version solving failed.

So, because yumi depends on firebase_messaging_web from git, version solving failed.

firebase_messaging_web: 3.7.1 should not have this issue, also you can give dependency_overrides a go


vaping/zmq will not bind to configured address if not run in debug mode

name: zmq_cdc
type: zeromq
bind: tcp://*:7461

runs fine with "vaping start" but doesn't bind port.
run it with "vaping start --debug" and it does bind to the port.

daemonize is closing it's fd


Rename Jade -> Pug

Jade was renamed Pug a couple years back.
https://github.com/pugjs/pug#rename-from-jade
This is just to update that so you can use language-pug to identify pug, instead of language-jade which is the deprecated name.

Thank you for contributing!


python3.5-jupyter: Fix build issue #17902

Motivation for this change
This fixes the python3.5-jupyter build issue #17902.
Details
A few modules needed fixing for this:

The pygobject3 package needed which and ncurses on darwin. (On darwin pygobject3 needs to find the libraries python3.5 was built with, in our case ncurses).
The pygobject3 package build script was confused because python3.5-config --ldflags contained -Wl,-stack_size,1000000, which upstream uses so some deep recursions in their unit tests work. However the python3.rb Formula on homebrew ignores this flag and doCheck is not set to true anyway, so we follow the same approach and compile python3.5 without the stack_size flag.
pyqt4 needs the target platform unsupported/macx-clang-libc++ in two phases: first the bootstrapping phase where qt stuff is found and second the build phase.

Things done

[ ] Tested using sandboxing (nix.useChroot on NixOS, or option build-use-chroot in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[x] OS X
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

This causes quite a few python3.5-dependee rebuilds, so hopefully it won't break anything.

Could you run nox-review pr 18025 to test whether any packages fail due to this change.

Sadly I run out of disk space from the required prebuilt-binary-downloads before I could even start building. Is there some option to do the nox-review in multiple steps?

@knedlsepp please apply the patches to the other "broken" interpreters as well.
Since there aren't any changes for Linux, aside from the pygobject change, we can merge it then.

I did apply the patch for 3.4, 3.5, 3.6. The version 3.3 didn't seem to be affected: (nix-shell -p python33 --pure --run "python3-config --ldflags")
I did apply it to version 3.6 also, even though this one does currently not build for darwin, because of the glibc dependency, which should be made linux only.
I also made the changes in pyqt only apply to darwin. I think however that the way I did it, nix will probably still need to rebuild it on linux. I don't know if this could be done in a better way.

could you rebase

@FRidh: Rebased. I however am currently not able to test it because of the broken 10.9 support.

Now that https://github.com/NixOS/nixpkgs/pull/18278 is merged this works again for me on 10.11.6

pushed also to new stable


KeepQuotedReply=true breaks bridging messages from Matrix

Enabling this feature breaks bridging and the default of KeepQuotedReply=false. The default is for replies to start with a newline, so it's not fully stripped out. No form of structured reply is used, at least when bridging to Discord/Telegram.

Nevermind, issue appears to be something else.


crashes after playing night of knights

Can you write a one-sentence description of the bug?
What is the current behavior?
Please provide the steps to reproduce and if possible a minimal demo of the problem.
What is the expected behavior?
Please tell us about your environment:

TJAPlayer3 version: vX.X.X-yyy
Operating system version:
Windows System Locale:
Display adapter:
Audio adapter:
Input device:

Other information
If you can provide any additional information, please do. If small, feel free to paste the content into the issue. If larger, consider linking to a Gist or a downloadable file.
Here are some suggestions:

Related issues
Config.ini file
Skin *Config.ini files
Stack trace(s)
Log file(s)
Example .tja file(s) (do not provide media)

So helpful.


Fit and finish for Insert Item...

[x] P2: Doubled "the the" in the messages "Please type the the value of ..."
[x] P2: We should add "Do not show again" functionality to these messages -> I'll do this as part of another PR
[ ] P1: After inserting, the location of the cursor should get revealed (currently the entire span gets revealed?)
[x] P3: Should we add validation (e.g. function name already exists, invalid names)?
[ ] P2: Now that we have a simple icon button to sort individual sections, it's a little disconcerting if I click, say, on the parameters' sort button and it says "Done sorting template!".  It would be better to be more specific "Parameters were sorted".  Ideally it would say "No parameters needed sorting" if appropriate.

After inserting, the location of the cursor should get revealed
I try to reveal the position where the text was inserted
        let pos = textEditor.document.positionAt(index);
        await textEditor.edit(builder => builder.insert(pos, text));
        textEditor.revealRange(new vscode.Range(pos, pos), vscode.TextEditorRevealType.Default);

For parameters I do not change the cursor. What should I reveal then?
What are the name validation rules for parameters, variables, functions, namespaces and outputs?

@neilpeterson What do you think about validation?  Is it worth the effort?

I am not aware of validation rules for parameter, variable, function, or output names. Checking both this doc, and this doc, the only requirements I've found is "Must be a valid JavaScript identifier" for both parameters and outputs.
Must be a valid JavaScript identifier

As for validation of duplicate names. We do throw an error on duplicate names for parameters, variabels, and outputs. So catching this at insert time would add some value.

My opinion is low priority assuming it's a simple addition. We can also let it sail without and adjust if needed / desired at a later time.

@nilshedstrom Sorry for the delay.  Re "After inserting, the location of the cursor should get revealed (currently the entire span gets revealed?)", here's an example:

Without looking at the code, it looks like you're revealing the entire inserted portion?  Which is fine unless you're also setting the cursor, in which case you should reveal the cursor location.
Also, I'd suggest trying TextEditorRevealType.InCenterIfOutsideViewport.

@nilshedstrom can we consider removing the sort icon from individual elements and only present it on the root level sections?

@neilpeterson

Fixed that. Did you want to remove the item from the context menu too?

@nilshedstrom can we consider removing the sort icon from individual elements and only present it on the root level sections?

Yes, please.

Did you want to remove the item from the context menu too?

No, the context menu items are more accessible/discoverable for someone with vision issues.

Last two items fixed by #727


app sorting

I was following the apps as an when they were added, I see that it is now sorted by name. it is difficult to follow new apps among the sea of apps listed here.
Can this be sorted by the date it is added again? or can there be option to sort it by the date or name with month based grouping?

Me too, i'm followong the electron new apps. I  prefer a "sorted by " option ...

Good point. We will work on a solution for this. Stay tuned!

I did some work to collect app submission dates from the git history. It's all here now: https://github.com/electron/electron-apps/blob/master/meta/dates.json
The build process will continue collecting dates for all apps going forward.
When you install this module with npm, the dates are included in the metadata for each app:
$yarn global add trymodule && trymodule electron-apps=apps

Then:
apps[0]

Which yields:
{ slug: '1clipboard',
  name: '1Clipboard',
  description: 'A universal clipboard managing app that makes it easy to access your clipboard from anywhere on any device',
  website: 'http://1clipboard.io',
  icon: '1clipboard-icon.png',
  icon32: '1clipboard-icon-32.png',
  icon64: '1clipboard-icon-64.png',
  icon128: '1clipboard-icon-128.png',
  date: '2016-03-31',
  iconColors: [ '#14538b', '#eff0f1', '#6b88a7', '#849cb4', '#8c9cb4' ]
}

Now that we have the data, the next step will be to surface on the website.

Apps are now sorted by date on the website, with newest submissions at the top. This has been fixed for a while, but I forgot to close the issue here.


Exclude slf4j classes from the spark-rapids jar

Exlcluding org.slf4j from the main plugin artifact, closes #3187
Signed-off-by: Gera Shegalov<EMAIL_ADDRESS>

build

build

It looks like the test failures are due to one of the test processes crashing. I cannot tell from the logs exactly what happened though.

the tests pass locally, trying to rerun CI

build


adding Microsoft infront of Teams

Don't need to prepend Teams with Microsoft except on first use. Closing without merging.


Incorrect install instruction for Vue2 in documentation

Install instruction for version 2 not work, because yarn add @storeon/vue install package latest version (correct for Vue3, not correct for Vue2).
Please add some dist-tag for Vue2 versions.

Hi,
Thanks for the report. You can install this package for Vue 2 with yarn add @storeon/vue@2.


ArenaBoundsPolygon, ArenaBoundsUnion, ArenaBoundsDifference, ArenaBoundsDonut, improvement to alliance raids, Masked Carnivale 28-32, caching, other small changes

Known issue with polygon arenas: - none, should work for any non-self-intersecting polygon without holes
Known issues with union arenas: - doesn't build correctly if there is more than one non-intersecting hole or more than 2 disjointed shapes
I added Quadtrees and Voronoi Diagrams while testing various algorithms for the polygon arenas, but they are not used in the current implementation. So if you don't have any use for the stuff there, consider deleting those two cs files.

Redacting this pull requests since I disagree with any licensing agreement you are trying to add. GTFO


Bug in fetching definition containing single quote (')

where the actual output should be this:

The error can be fixed by not using split()
The json where the issue can be found: https://api.dictionaryapi.dev/api/v2/entries/en_US/mountain (or any other definition text containing a single quote)

I can help to resolve this issue.. will you pls assign?

issue resolved!

not yet fixed
you can open any other dictionary api if you want. just make sure its completely open source :)


More detailed time of day for warnings

Current Implementation
If you have been near a positive tested person for a longer time you get a warning message with day, month and year when the encounter happened.
Suggested Enhancement
Beside the date also the time of the day like morning, forenoon, midday, afternoon, evening, night should be displayed so one can better estimate the risk.
Expected Benefits
As I got the warning I was unable to estimate my own risk:

Was it in the morning when using public transports while wearing a mask?
Was it in the forenoon during work while not wearing a mask from the same room, meetings, neighbour rooms or even other companies on the same floor?
Was it at midday when eating in the cantina while not wearing a mask?
Was it in the afternoon during work while not wearing a mask from the same room, meetings, neighbour rooms or even other companies on the same floor?
Was it in the evening when using public transports or shopping while wearing a mask?
Was it at the night from my neighbours?

So when I would have known a more specific timeframe I would be able to estimate my personal risk much more better and I am also able to specific warn other contact persons.

Hey @marty2022 👋
Thanks for the proposal!
The Corona-Warn-App is using the Google/Apple Exposure Notification System / Framework. It records and stores the received BLE beacons.
When CWA is checking for risky encounters, it downloads the list of positive keys from the server and hands it over to the Exposure Notification Framework (ENF). This then checks whether a key from the server is also stored on your local device. If yes, this means you encountered a later positive tested person. In this case, the ENF hands ofer the relevant Exposure Windows to the CWA. This includes, besides some other things, only the date of the encounter but not the time.
So, in conclusion, this proposal is not possible to be implemented without Apple & Google changing their Exposure Notification System.

I opened an issue regarding this in the wishlist some time ago: https://github.com/corona-warn-app/cwa-wishlist/issues/266

If you want to dive deeper, take a look at the documentation from Apple on the Exposure Notification Framework or/and at the documentation from Google on the Exposure Notification System.
Enjoy Sunday!

What a pity, so changes are very low that this will get changed.
But thank you very much for the detailed explanation!

Hi @marty2022, yes chances are little... As @Ein-Tim explained already, there are technical limitations that do not allow this. The app uses a functionality (the ENF) from the operating system (Android, or iOS, respectively) in order to assess the risk.
There is another reasons, why this probably would not be implemented, even if it was technical possible: Data privacy.
On of the main purposes of the app is contact tracing: You as a user should be warned if a possible risk encounter happened. Give gives you the possibility to get advice and most probably you will be sent to get a test (if it was a high risk encounter = red card). For this purpose the time does not add any further useful value.
However, if you had the time, you could maybe identify the person, who shared his positive test result anonymously. In this case his privacy would be violated and the acceptance of the app might be decreased.
With the current implementation the app serves amongst others the purpose of contact tracing, i.e. warning user, which then ideally get tested, and on the other side, at the same time it values privacy.

The fork corona-contact-tracing-germany does allow to get more information. And together with the app  Corona Warn Companion you get even more.

Hi @marty2022, yes chances are little... As @Ein-Tim explained already, there are technical limitations that do not allow this. The app uses a functionality (the ENF) from the operating system (Android, or iOS, respectively) in order to assess the risk.
There is another reasons, why this probably would not be implemented, even if it was technical possible: Data privacy.
On of the main purposes of the app is contact tracing: You as a user should be warned if a possible risk encounter happened. Give gives you the possibility to get advice and most probably you will be sent to get a test (if it was a high risk encounter = red card). For this purpose the time does not add any further useful value.
However, if you had the time, you could maybe identify the person, who shared his positive test result anonymously. In this case his privacy would be violated and the acceptance of the app might be decreased.
With the current implementation the app serves amongst others the purpose of contact tracing, i.e. warning user, which then ideally get tested, and on the other side, at the same time it values privacy.
Corona-Warn-App Open Source Team

The problem with this argument is that currently it is easily possible for technically savy users to get the exact timestamp by rooting or installing cctg and then using the companion app to find the exact timesamp.
Why do technically savy people have the possibility (and right?) do deanonymize their contacts via time but not "normal" users?
Either the timestamp should be protected using encryption, hashing or access to key database so that technically savy people also do not have access
or
(my preferred solution) the timestamp should be available to everyone.
This seems to be a very frequent feature request.
If Google and Apple have not categorically rejected changes to the ENF one way to convince them might be to make this an opt in/out feature where you only recieve the exact time if you share (allow using) your exact time as well.

@cvoinf Awesome, thank you very much for these links. Too bad that Warn-App-Companion needs root-permissions (or the Corona-Contact-Tracing-App which is not so well tested as they say).
@dsarkar If I only meet one person on a day where I get a positive warning I can also identify this person with the current implementation.
It's always a balance between privacy and benefit. And having 6 timeslots per day instead of 1 would greatly improve the benefit while not decreasing privacy too much.

Hi @marty2022

If I only meet one person on a day where I get a positive warning I can also identify this person with the current implementation.

Sure, in real life scenario, you probably now this person and had been informed by him directly anyway.

It's always a balance between privacy and benefit.
That is exactly the point, and current view is that the offered solution is the "right" balance. Of course to find this balance and to agree on common terms is not an easy task. Note that the current ENF by Apple and Google (which limits the functionality to the day of the encounter, and time is unknown by the tracing apps which make use of the OS ENF) is a transnational solution, and many considerations had to go into the definition to achieve acceptance und a working system.

I suggest to move this issue to the wishlist repo.


Next.js 14 & Supabase SSR

Closes #115 #190 #200 #222 #244 #254 #262 #271 #248 #223 #274
This PR updates all packages and switches from the now deprecated auth helpers to Supabase SSR.

Name and email updating is working, but if Jon or Thor or someone wants to look at password reset (account/recover-password) that would be awesome.
Added shadcn UI toast for error and status handling
Heads up, I have also encountered this issue https://github.com/supabase/auth-helpers/issues/696 with Supabase SSR.

Oh, wow! Probably too much for one PR, but some nice changes. I was just finishing up a PR to upgrade to NextJS 14 and implement server actions myself, but you beat me to it!

You've implemented a bunch of different bug fixes and features and opinionated refactorings in a single PR. Some great stuff here, but I would love to see this PR broken down a bit more for easier review.

It can definitely be broken down if needed. A lot of stuff is from existing PRs (including yours) just to close them out. I tried not to get too opinionated, rather just to deliver on originally intended features. The server actions for updating the name and email were already present, for example, just disabled. The main issue is that there wasn't a great way of providing success and error state messages. In the future I would advocate dropping the auth UI package and switching to server-side auth with toast success/error states to make the project more consistent.

I spent most of the day reviewing your first couple commits and sorting them into three different branches, in some cases with slight changes. (Let me know how or if you want me to handle opening PRs from these branches, because I want you to get credit for your excellent work.)

https://github.com/chriscarrollsmith/nextjs-subscription-payments/tree/supabase-auth, which updates how we create the supabase client
https://github.com/chriscarrollsmith/nextjs-subscription-payments/tree/stripe-checkout, which upgrades to the latest Stripe API version and changes some of the checkout behavior
https://github.com/chriscarrollsmith/nextjs-subscription-payments/tree/ui-refactor, which moves the Card component into its own file and gives Button a displayName

The supabase-auth stuff looks good, though I haven't comprehensively tested it yet. Required some reading of docs, and I learned some things. I added a few more comments than you, but otherwise my branch is in line with your code. Your ui-refactor also looks good to me, although I've placed Card.tsx into a Card subfolder and exported it from an index.ts file to match the rest of the ui components.
The stripe-checkout stuff I'm unsure about. When I try to change my API version in stripe.ts to match yours, I get a type error. The type is apparently set by my install of the latest version of the stripe library in node_modules. It's possible that the installation process is somehow pulling my account's API version from my Stripe dashboard. There probably needs to be some documentation in the README about how to make sure the API version specified in 'stripe.ts' matches the API version of your account and the API version permitted by the stripe module's type definitions.
I also adjusted some of what you changed in the create-checkout route. I put the cancel_url back in, so that Stripe checkout will provide a 'back' button for the user to cancel checkout if they want. And instead of dropping all support for free trials, I used 'trial_period_days: price.trial_period_days,' which should dynamically allow for both trialing and non-trialing subscription as controlled from the Stripe dashboard.
I haven't looked at your toast or password recovery code yet at all, but I am excited to dive into that and also do some live testing tomorrow, because those are features I've been wanting to add myself, and you are going to save me a lot of time!

I spent most of the day reviewing your first couple commits and sorting them into three different branches, in some cases with slight changes. (Let me know how or if you want me to handle opening PRs from these branches, because I want you to get credit for your excellent work.)

Thank you, yeah maybe let's see if Thor or Jon wants to take a look at the current PR first. My last PR was also quite big but did end up getting merged with some revisions. In the meantime are you able to suggest the changes here?

The supabase-auth stuff looks good, though I haven't comprehensively tested it yet. Required some reading of docs, and I learned some things. I added a few more comments than you, but otherwise my branch is in line with your code. Your ui-refactor also looks good to me, although I've placed Card.tsx into a Card subfolder and exported it from an index.ts file to match the rest of the ui components.

Not sure that I changed much as far as auth goes, it's still using supabase-provider.tsx with Auth UI. I think the main thing is that I switched sign out to a server action. Matching Card with the other components is a good change!

The stripe-checkout stuff I'm unsure about. When I try to change my API version in stripe.ts to match yours, I get a type error. The type is apparently set by my install of the latest version of the stripe library in node_modules. It's possible that the installation process is somehow pulling my account's API version from my Stripe dashboard. There probably needs to be some documentation in the README about how to make sure the API version specified in 'stripe.ts' matches the API version of one's Stripe account and the API version permitted by the stripe module's type definitions.

Come to think of it I may have updated my Stripe version from the Stripe dashboard at some point. The reason I changed the version in stripe.ts is because I was getting a type error Type '"2022-11-15"' is not assignable to type '"2023-10-16"'.ts(2322) Do you not get that?

I also adjusted some of what you changed in the create-checkout route. I put the cancel_url back in, so that Stripe checkout will provide a 'back' button for the user to cancel checkout if they want. And instead of dropping all support for free trials, I used 'trial_period_days: price.trial_period_days,' which should dynamically allow for both trialing and non-trialing subscription, as controlled from the Stripe dashboard. (The Stripe docs say setting trial_end or trial_period_days is preferred over setting trial_from_plan, though I can't see why, as the latter seems more secure to me at a glance.)

Dropped cancel_url is my mistake, definitely should be corrected. Nice idea on the trial period too.

I haven't looked at your toast or password recovery code yet at all, but I am excited to dive into that and also do some live testing tomorrow, because those are features I've been wanting to add myself, and you are going to save me a lot of time!

Yeah I think you'll find a useEffect in the toaster listening for URL param changes is quite an elegant solution for handling notifications globally with all the components going server side. Password recovery is not working like expected currently so be aware. I was hoping someone from Supabase could take a look at it. We're not supposed to @ people, right 😅

I'll see if I can help you debug the password recovery. Re: Stripe, I got
exactly the opposite type error.
On Wed, Nov 29, 2023, 12:25 AM Matt @.***> wrote:

I spent most of the day reviewing your first couple commits and sorting
them into three different branches, in some cases with slight changes. (Let
me know how or if you want me to handle opening PRs from these branches,
because I want you to get credit for your excellent work.)
Thank you, yeah maybe let's see if Thor or Jon wants to take a look at the
current PR first. My last PR was also quite big but did end up getting
merged with some revisions. In the meantime are you able to suggest the
changes here?
The supabase-auth stuff looks good, though I haven't comprehensively
tested it yet. Required some reading of docs, and I learned some things. I
added a few more comments than you, but otherwise my branch is in line with
your code. Your ui-refactor also looks good to me, although I've placed
Card.tsx into a Card subfolder and exported it from an index.ts file to
match the rest of the ui components.
Not sure that I changed much as far as auth goes, it's still using
supabase-provider.tsx with Auth UI. I think the main thing is that I
switched sign out to a server action. Matching Card with the other
components is a good change!
The stripe-checkout stuff I'm unsure about. When I try to change my API
version in stripe.ts to match yours, I get a type error. The type is
apparently set by my install of the latest version of the stripe library
in node_modules. It's possible that the installation process is somehow
pulling my account's API version from my Stripe dashboard. There probably
needs to be some documentation in the README about how to make sure the API
version specified in 'stripe.ts' matches the API version of one's Stripe
account and the API version permitted by the stripe module's type
definitions.
Come to think of it I may have updated my Stripe version from the Stripe
dashboard at some point. The reason I changed the version in stripe.ts is
because I was getting a type error Type '"2022-11-15"' is not assignable
to type '"2023-10-16"'.ts(2322) Do you not get that?
I also adjusted some of what you changed in the create-checkout route. I
put the cancel_url back in, so that Stripe checkout will provide a 'back'
button for the user to cancel checkout if they want. And instead of
dropping all support for free trials, I used 'trial_period_days:
price.trial_period_days,' which should dynamically allow for both trialing
and non-trialing subscription, as controlled from the Stripe dashboard.
(The Stripe docs say setting trial_end or trial_period_days is preferred
over setting trial_from_plan, though I can't see why, as the latter seems
more secure to me at a glance.)
Dropped cancel_url is my mistake, definitely should be corrected. Nice
idea on the trial period too.
I haven't looked at your toast or password recovery code yet at all, but I
am excited to dive into that and also do some live testing tomorrow,
because those are features I've been wanting to add myself, and you are
going to save me a lot of time!
Yeah I think you'll find a useEffect in the toaster listening for URL
param changes is quite an elegant solution for handling notifications
globally with all the components going server side. Password recovery is
not working like expected currently so be aware. I was hoping someone from
Supabase could take a look at it. We're not supposed to @ people, right 😅
—
Reply to this email directly, view it on GitHub
https://github.com/vercel/nextjs-subscription-payments/pull/278#issuecomment-1831244006,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASCYPGN5TJYXYGYJ4LRICTTYG3BLRAVCNFSM6AAAAAA75KVAIOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZRGI2DIMBQGY
.
You are receiving this because you commented.Message ID:
@.***>

I'm fine with one large PR 👍 Thank you for opening this!

Am I wrong in thinking line 104 in 'app/account/page.tsx' should have 'status_description', not 'error_description'?

A few thoughts on the toasts.

They are pretty bulky, with several new module files, several new dependencies, and a couple new configs. That's not necessarily bad, but it's maybe not ideal for a starter template. I will defer to the Vercel folks on this one.
I like the look of the toasts, but if you close one by clicking the "x", the toast's  container is "focused" and gets a pink border, which remains visible in the lower-right-hand corner of the page when the toast is closed. To fix this, change *:focus: in main.css to *:focus:not(ol).
Line 104 in 'app/account/page.tsx' should have status_description, not error_description. On the same page, I encountered at least one unhandled error condition. Instead of making custom error messages for every error condition, I suggest just passing error.message as the error_description.

For reference, my lightly edited 'toasts' feature branch is here: https://github.com/chriscarrollsmith/nextjs-subscription-payments/tree/toasts

Regarding the Stripe type error, both the Stripe docs and the code editor hints claim that 'stripe-js' only allows the latest API version, but their versioning page claims that older versions of 'stripe-js' set the type based on your account's API version. Since I've made sure I'm on the latest version of 'stripe-js' and it's still only letting me use '2022-11-15', I have to conclude that the docs are wrong, and it's still the user's account version that's being exported as the StripeConfig type.
Interestingly, the documentation for setting a global apiVersion says, 'If you wish to remain on your account's default API version, you may pass null or another version instead of the latest version, and add a @ts-ignore comment here and anywhere the types differ between API versions.' For purposes of making this template user-friendly and preventing additional setup steps, maybe a null value and a @ts-ignore comment would indeed be the way to go.

I think what I'm going to do, once I finish my review, is open a pull request to your 'dalkommatt:nextjs-14-supabase-ssr' branch with my suggested adjustments. That way you don't have to make all these changes manually. Thanks again for all your hard work on this. It's impressive stuff.

I think what I'm going to do, once I finish my review, is open a pull request to your 'dalkommatt:nextjs-14-supabase-ssr' branch with my suggested adjustments. That way you don't have to make all these changes manually. Thanks again for all your hard work on this. It's impressive stuff.

Sounds like a plan, I'll look forward to it!

@dijonmusters as the project is currently set up, the listener doesn't seem to be detecting any auth change events. I tried logging them, and got nada. However, the AuthUI component is using the context exported from supabase-provider.tsx, and I so far haven't been able to get it to work without it. (I admit I'm a total neophyte with both NextJS and Supabase, so I don't really know what I'm doing.)

Regarding password recovery:
The AuthUI package apparently just doesn't fully work as intended. It is also grossly under-documented, and the guy who runs it seems to reject sensible PRs. However, here's what I've been able to figure out.
First, many people have created issues indicating that the PASSWORD_RECOVERY event doesn't fire. I don't know exactly why not, but it seems like this feature isn't working. And even if it did work, I'm not sure it would be compatible with our current application flow, which redirects the user to 'auth/callback' for authentication by magic link.
Second, magic links work by taking the user to the Supabase server, which then redirects them to 'auth/callback' with an API request that contains a code we can exchange for a session authorizing the user. The magic link contains 'type=recovery', but this information unfortunately doesn't get passed along in the request, so there's no way to tell in our 'auth/callback' endpoint whether the user has come via a password recovery or just a regular magic link.
Third, the redirect destination (currently 'auth/callback') is controlled from the redirectTo prop in the Auth component. Unfortunately, this prop controls the redirect destination for both password recovery and magic links, and there aren't separate props for setting separate destinations for each.
However, it appears that there is a workaround. This isn't documented anywhere, but the AuthUI maintainer dropped enough hints that I was able to figure it out. It looks like you can set showLinks to false, which will remove the 'sign up' and 'forgot your password' links under the Auth component. Then you can add your own 'sign up' and 'forgot your password' links, and use them to manually toggle the Auth component's 'view' prop (to control whether it is a 'sign_in', 'sign_up', 'forgotten_password', 'update_password', or 'magic_link' view) as well as change its 'redirect_to' prop to set different redirect destinations for different views. And we can add a new route, in addition to 'auth/callback,' that redirects the user to an update password page.
It's late and I need to get to bed, but tomorrow I will take a crack at implementing this workaround.

Regarding password recovery:
The AuthUI package apparently just doesn't fully work as intended. It is also grossly under-documented, and the guy who runs it seems to reject sensible PRs. However, here's what I've been able to figure out.
First, many people have created issues indicating that the PASSWORD_RECOVERY event doesn't fire. I don't know exactly why not, but it seems like this feature isn't working. And even if it did work, I'm not sure it would be compatible with our current application flow, which redirects the user to 'auth/callback' for authentication by magic link.
Second, magic links work by taking the user to the Supabase server, which then redirects them to 'auth/callback' with an API request that contains a code we can exchange for a session authorizing the user. The magic link contains 'type=recovery', but this information unfortunately doesn't get passed along in the request, so there's no way to tell in our 'auth/callback' endpoint whether the user has come via a password recovery or just a regular magic link.
Third, the redirect destination (currently 'auth/callback') is controlled from the redirectTo prop in the Auth component. Unfortunately, this prop controls the redirect destination for both password recovery and magic links, and there aren't separate props for setting separate destinations for each.
However, it appears that there is a workaround. This isn't documented anywhere, but the AuthUI maintainer dropped enough hints that I was able to figure it out. It looks like you can set showLinks to false, which will remove the 'sign up' and 'forgot your password' links under the Auth component. Then you can add your own 'sign up' and 'forgot your password' links, and use them to manually toggle the Auth component's 'view' prop (to control whether it is a 'sign_in', 'sign_up', 'forgotten_password', 'update_password', or 'magic_link' view) as well as change its 'redirect_to' prop to set different redirect destinations for different views. And we can add a new route, in addition to 'auth/callback,' that redirects the user to an update password page.
It's late and I need to get to bed, but tomorrow I will take a crack at implementing this workaround.

Auth UI doesn't play very nicely with SSR. It might be better to remove this as a dependency entirely and manually recreate a stable version of the functionality we actually want - rather than hacky workarounds to make it kind of work. Even if we stripped it back to just using a single OAuth provider - such as GitHub. This would mean we wouldn't need to have nicely styled form inputs with handling multiple states or implement resetting password flows. Boiling it down, this template is solving the problem of getting up and running with a SaaS project as quickly as possible. To solve that problem, we need a way to authenticate. But we don't need several ways to authenticate.
What are your thoughts?

Auth UI doesn't play very nicely with SSR. It might be better to remove this as a dependency entirely and manually recreate a stable version of the functionality we actually want - rather than hacky workarounds to make it kind of work. Even if we stripped it back to just using a single OAuth provider - such as GitHub. This would mean we wouldn't need to have nicely styled form inputs with handling multiple states or implement resetting password flows. Boiling it down, this template is solving the problem of getting up and running with a SaaS project as quickly as possible. To solve that problem, we need a way to authenticate. But we don't need several ways to authenticate.
What are your thoughts?

Personally I'm all for going passwordless. How about one OAuth provider and a magic link option? That way you can still sign in with just email.

I recommend these changes to:

refactor functions from utils/supabase/server.ts to where they are used throughout the codebase
remove Auth UI
implement OAuth with GitHub
remove Supabase provider
refactor auth flow to be 100% server-side

Also, Supabase OAuth is still a bit buggy

Do you have an example of this? There were some issues with cookie chunking when we launched the @supabase/ssr package, but to my knowledge it should be working correctly now 👍

In the absence of good documentation, a lot of frustrated developers may also benefit from having this repo as an example of how to use AuthUI

I think it is more like Auth UI is not entirely compatible with SSR and I'm not sure it ever will be. There are some hacky workarounds to get things mostly working, but the package would require significant work to make it properly compatible. Best to avoid using it in this template until it is fully compatible 👍

@dijonmusters see what you think of the magic link login. If not I can always roll back 😉

Also, Supabase OAuth is still a bit buggy

Do you have an example of this? There were some issues with cookie chunking when we launched the @supabase/ssr package, but to my knowledge it should be working correctly now 👍

I keep seeing open Supabase issues related to OAuth failing if the user tries more than one OAuth provider that uses the same email address. Apparently Supabase hasn't yet solved how to link them. I haven't tested OAuth much myself, so this is all secondhand.

@dalkommatt I see you made some changes to types_db.ts in your last commit. Were those changes auto-generated from the Supabase CLI, or did you make them manually?
I ask because that file is meant to be auto-generated from the database via the Supabase CLI. The database, in turn, is meant to be auto-generated from schema.sql. So make sure you support that workflow, that you don't make any manual changes to types_db.ts, and that any changes to types_db.ts are matched by corresponding changes in schema.sql.

@chriscarrollsmith https://github.com/supabase/supabase-js/commit/4d35d26d1ecd8c2f5b0b7e3066166d56cf284262

Turns out I was making this much more complicated than it needs to be. Coming at it fresh this morning, I managed to greatly simplify and remove the API endpoints. All the magic now happens faster and more smoothly in server action helper functions.

I also added simple boolean switches to utils/auth-helpers.ts in my PR to control allowed sign-in methods, so you can go passwordless, or not, with the switch of a toggle.

I want to just say, I really appreciate all of the time and effort that everyone has put into this project. I am just starting my own Full Stack Dev journey. I am learning so much, and it is wonderful to see such an active and selfless community!

@rayne1066 graciously did some testing and identified some bugs in URL handling, trial period handling, and customer creation which I have fixed in my open PR.

I am inclined to use the hacky workaround, mostly because building a custom UI sounds like a lot of work, and I'd like this repo to demonstrate how to do authentication comorehensively, not just OAuth. (Also, Supabase OAuth is still a bit buggy.) In the absence of good documentation, a lot of frustrated developers may also benefit from having this repo as an example of how to use AuthUI. But I agree with you that it sucks to have to mix our SSR workflow throughout the rest of the application with client-side context in this one case, to support this one dumb dependency.
…
On Thu, Nov 30, 2023, 11:39 PM Jon Meyers @.> wrote: Regarding password recovery: The AuthUI package apparently just doesn't fully work as intended. It is also grossly under-documented, and the guy who runs it seems to reject sensible PRs. However, here's what I've been able to figure out. First, many people have created issues indicating that the PASSWORD_RECOVERY event doesn't fire. I don't know exactly why not, but it seems like this feature isn't working. And even if it did work, I'm not sure it would be compatible with our current application flow, which redirects the user to 'auth/callback' for authentication by magic link. Second, magic links work by taking the user to the Supabase server, which then redirects them to 'auth/callback' with an API request that contains a code we can exchange for a session authorizing the user. The magic link contains 'type=recovery', but this information unfortunately doesn't get passed along in the request, so there's no way to tell in our 'auth/callback' endpoint whether the user has come via a password recovery or just a regular magic link. Third, the redirect destination (currently 'auth/callback') is controlled from the redirectTo prop in the Auth component. Unfortunately, this prop controls the redirect destination for both password recovery and magic links, and there aren't separate props for setting separate destinations for each. However, it appears that there is a workaround. This isn't documented anywhere, but the AuthUI maintainer dropped enough hints that I was able to figure it out. It looks like you can set showLinks to false, which will remove the 'sign up' and 'forgot your password' links under the Auth component. Then you can add your own 'sign up' and 'forgot your password' links, and use them to manually toggle the Auth component's 'view' prop (to control whether it is a 'sign_in', 'sign_up', 'forgotten_password', 'update_password', or 'magic_link' view) as well as change its 'redirect_to' prop to set different redirect destinations for different views. And we can add a new route, in addition to 'auth/callback,' that redirects the user to an update password page. It's late and I need to get to bed, but tomorrow I will take a crack at implementing this workaround. Auth UI doesn't play very nicely with SSR. It might be better to remove this as a dependency entirely and manually recreate a stable version of the functionality we actually want - rather than hacky workarounds to make it kind of work. Even if we stripped it back to just using a single OAuth provider - such as GitHub. This would mean we wouldn't need to have nicely styled form inputs with handling multiple states or implement resetting password flows. Boiling it down, this template is solving the problem of getting up and running with a SaaS project as quickly as possible. To solve that problem, we need a way to authenticate. But we don't need several ways to authenticate. What are your thoughts? — Reply to this email directly, view it on GitHub <#278 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASCYPGLZOMTJ5NPD4KIM2UTYHFNQTAVCNFSM6AAAAAA75KVAIOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZVGQ2DOMBSGI . You are receiving this because you commented.Message ID: @.>

Can't we just have forgot password just be like send magic link. Is it possible to have the authui only send the magic link to confirmed emails.
And then in the user account profile allow them to change their password if they signed up with password.

I have encountered what may be a limitation of server-side auth flow, or may just be a problem with how we implemented it in this PR: we are continuously making many requests to the Supabase auth API, such that it's possible to exceed rate limits with only a single user on the app! I haven't yet gone deep on this, but it seems like some combination of caching and passing down the tree might be needed to reduce API load. I need to experiment with adding console logs to see exactly where all the calls are being triggered from.

I have encountered what may be a limitation of server-side auth flow, or may just be a problem with how we implemented it in this PR: we are continuously making many requests to the Supabase auth API, such that it's possible to exceed rate limits with only a single user on the app! I haven't yet gone deep on this, but it seems like some combination of caching and passing down the tree might be needed to reduce API load. I need to experiment with adding console logs to see exactly where all the calls are being triggered from.

Is this still happening if you pull down the recent changes that exports a matcher from middleware?

Love the teamwork here 😄 Looking forward to seeing this get merged.

I have encountered what may be a limitation of server-side auth flow, or may just be a problem with how we implemented it in this PR: we are continuously making many requests to the Supabase auth API, such that it's possible to exceed rate limits with only a single user on the app! I haven't yet gone deep on this, but it seems like some combination of caching and passing down the tree might be needed to reduce API load. I need to experiment with adding console logs to see exactly where all the calls are being triggered from.

Is this still happening if you pull down the recent changes that exports a matcher from middleware?

I had already pulled those changes. I will do some work this week to see what's going on.

Nice one! When will we see it live?

This looks great! Awesome work everyone! 🎉
I think it is ready to merge, so long as @chriscarrollsmith is no longer getting that API Auth Error with a matcher exported from middleware.ts?

@dijonmusters @dalkommatt  where is supabase.auth.onAuthStateChange listener? When user signs out from one browser window it's basically not redirecting from another windows.
Should not we have supabase.auth.onAuthStateChange listener to log out user from other browser tabs/window.

I agree with @nonamecodi, this question tags on to that one

@dijonmusters @dalkommatt where is supabase.auth.onAuthStateChange listener? When user signs out from one browser window it's basically not redirecting from another windows. Should not we have supabase.auth.onAuthStateChange listener in middleware to log out user from other browser tabs/window.

onAuthStateChange is no longer required for the auth flow as we are doing everything server-side. We are explicitly redirecting after the user signs in in /app/auth/callback/route.ts and after the user signs out in /components/ui/Navbar/Navbar.tsx.
Previously the auth listener was required as it was the only way to know when the authentication process had completed. That is not the case with the code exchange route in the PKCE flow used by the auth-helpers and ssr packages 👍

Thanks for explanation @dijonmusters. But what will happen when

users open the app in two tabs.
Tab 1 and Tab 2.
Now user logs out in Tab 2
- Should not the Tab 1 also need to logs out.

I thought onAuthStateChange handle this scenario.
I verified the PR but above scenario does not work.

@dijonmusters @dalkommatt where is supabase.auth.onAuthStateChange listener? When user signs out from one browser window it's basically not redirecting from another windows. Should not we have supabase.auth.onAuthStateChange listener in middleware to log out user from other browser tabs/window.

onAuthStateChange is no longer required for the auth flow as we are doing everything server-side. We are explicitly redirecting after the user signs in in /app/auth/callback/route.ts and after the user signs out in /components/ui/Navbar/Navbar.tsx.
Previously the auth listener was required as it was the only way to know when the authentication process had completed. That is not the case with the code exchange route in the PKCE flow used by the auth-helpers and ssr packages 👍

Have same question as @tmanager2025. How to log out users from all other logged in tabs, when they signed out from one tab.

Sorry I've been AWOL for a week or two. Have been down and out with the flu, and also preoccupied with another project. Will get back to this next week.

@dijonmusters @dalkommatt where is supabase.auth.onAuthStateChange listener? When user signs out from one browser window it's basically not redirecting from another windows. Should not we have supabase.auth.onAuthStateChange listener in middleware to log out user from other browser tabs/window.

onAuthStateChange is no longer required for the auth flow as we are doing everything server-side. We are explicitly redirecting after the user signs in in /app/auth/callback/route.ts and after the user signs out in /components/ui/Navbar/Navbar.tsx.
Previously the auth listener was required as it was the only way to know when the authentication process had completed. That is not the case with the code exchange route in the PKCE flow used by the auth-helpers and ssr packages 👍

Have same question as @tmanager2025. How to log out users from all other logged in tabs, when they signed out from one tab. Should not we listen to onAuthStateChange event to do this.

The onAuthStateChange function should work to solve that specific use case, but not sure this problem needs to be solved for this template - every line of code included increases the complexity and maintenance burden for everyone that uses it.
It is pretty common for auth state to be checked on navigation or refresh, so if someone has logged out in a different tab, it should be expected that the app running in another tab is in a different state until they refresh or navigate somewhere that requires authentication.
I would recommend leaving this out of the template, and up to the individual building the app if this is how they want to handle their logout flow 👍

This looks great! Awesome work everyone! 🎉
I think it is ready to merge, so long as @chriscarrollsmith is no longer getting that API Auth Error with a matcher exported from middleware.ts?

@chriscarrollsmith if you get a chance, could you check whether this one is resolved for you with the matcher?

onAuthStateChange

@dijonmusters I think this template should have basic best practices. We removed onAuthStateChange functionality which was previously there in the template.
I am confused how to do this. I took reference of this template so many time in past.
I think onAuthStateChange needs to be added to make the basic Login/Logout scenarios work properly which is main motive of this template.
Having that code will show how to do it in real world because this template is main reference for authentication and payment.

@dijonmusters @dalkommatt where is supabase.auth.onAuthStateChange listener? When user signs out from one browser window it's basically not redirecting from another windows. Should not we have supabase.auth.onAuthStateChange listener in middleware to log out user from other browser tabs/window.

onAuthStateChange is no longer required for the auth flow as we are doing everything server-side. We are explicitly redirecting after the user signs in in /app/auth/callback/route.ts and after the user signs out in /components/ui/Navbar/Navbar.tsx.
Previously the auth listener was required as it was the only way to know when the authentication process had completed. That is not the case with the code exchange route in the PKCE flow used by the auth-helpers and ssr packages 👍

Have same question as @tmanager2025. How to log out users from all other logged in tabs, when they signed out from one tab. Should not we listen to onAuthStateChange event to do this.

The onAuthStateChange function should work to solve that specific use case, but not sure this problem needs to be solved for this template - every line of code included increases the complexity and maintenance burden for everyone that uses it.
It is pretty common for auth state to be checked on navigation or refresh, so if someone has logged out in a different tab, it should be expected that the app running in another tab is in a different state until they refresh or navigate somewhere that requires authentication.
I would recommend leaving this out of the template, and up to the individual building the app if this is how they want to handle their logout flow 👍

@dijonmusters I agree with @myorgmanager  is reference for many people for Login and Subscription. Having no way to Logout users on another tabs/window is bad once they logout.
Would love to see have this feature in this PR which is removed and we lost that functionality.
It is important to show how this done in RSC and supabase.

for the website i built, i set onlyThirdPartyProviders to true and implemented clear all cookies when the user signs out. The website has no users though except for me so idk.

for the website i built, i set onlyThirdPartyProviders to true and implemented clear all cookies when the user signs out. The website has no users though except for me so idk.

I think @dijonmusters's point is that they are logged out in the other tab, though it won't be obvious unless they refresh or navigate somewhere. I will look into how hard it would be to implement onAuthStateChange; I haven't used this before.

This looks great! Awesome work everyone! 🎉
I think it is ready to merge, so long as @chriscarrollsmith is no longer getting that API Auth Error with a matcher exported from middleware.ts?

@chriscarrollsmith if you get a chance, could you check whether this one is resolved for you with the matcher?

Sorry for taking a while to get back to you. When I look in my Supabase logs, I see two things. First, there is some redundancy in the API calls. Here I navigated to the front page, which triggered, apparently, two API calls:

The other thing I'm seeing here is that 401 'invalid sub claim' error. That's not triggering any kind of problem on-page or any error in my console/terminal, and it seems to only occur when the user is logged out, so maybe it's expected behavior; I don't know.
Here's another example of the redundant API burden. Logging in triggers four API requests:

I'm uncertain what's causing this, but I think it could add up and exceed rate limits pretty fast.

By the way, on my PR, I updated the README to document how to develop locally with Supabase.

@dijonmusters actually the problem of redundant API calls was much worse than I described above. The Supabase 'auth' API log showed only two calls per page load, but the 'edge' API log showed a lot more than that. When I added a console log in the middleware to see what routes it was being rendered on, the reason for the problem became obvious:

Calling middleware for route:  /
Calling middleware for route:  /vercel.svg
Calling middleware for route:  /nextjs.svg
Calling middleware for route:  /stripe.svg
Calling middleware for route:  /supabase.svg
Calling middleware for route:  /github.svg

Accordingly, I updated the pattern matcher:
export const config = {
  matcher: [
    /*
     * Match all request paths except for the ones starting with:
     * - _next/static (static files)
     * - _next/image (image optimization files)
     * - favicon.ico (favicon file)
     * Feel free to modify this pattern to include more paths.
     */
    '/((?!_next/static|_next/image|favicon.ico|.*\\.(?:svg|png|jpg|jpeg|gif|webp)$).)*',
  ],
}

So that issue, at least, has been resolved. And it looks like the '401: invalid claim: missing sub claim' log entry is just the expected response of Supabase's 'user' API endpoint when the user is not logged in, so that's not a problem.
I am still getting two API requests to Supabase's auth API when I load the Pricing page. One is from the middleware, and one is from the user API when we conditionally render the page based on whether the user is logged in. So there's still some redundancy there, but it's probably unavoidable, and I think the change to the pattern matcher will mostly resolve the rate-limit problem I was running into.
As far as I'm concerned, this PR is ready to be merged. The only question still to be resolved is how you want to reconcile @dalkommatt's version with mine.

@dijonmusters actually the problem of redundant API calls was much worse than I described above. The Supabase 'auth' API log showed only two calls per page load, but the 'edge' API log showed a lot more than that. When I added a console log in the middleware to see what routes it was being rendered on, the reason for the problem became obvious:

Calling middleware for route:  /
Calling middleware for route:  /vercel.svg
Calling middleware for route:  /nextjs.svg
Calling middleware for route:  /stripe.svg
Calling middleware for route:  /supabase.svg
Calling middleware for route:  /github.svg

Accordingly, I updated the pattern matcher:
export const config = {
  matcher: [
    /*
     * Match all request paths except for the ones starting with:
     * - _next/static (static files)
     * - _next/image (image optimization files)
     * - favicon.ico (favicon file)
     * Feel free to modify this pattern to include more paths.
     */
    '/((?!_next/static|_next/image|favicon.ico|.*\\.(?:svg|png|jpg|jpeg|gif|webp)$).)*',
  ],
}

So that issue, at least, has been resolved. And it looks like the '401: invalid claim: missing sub claim' log entry is just the expected response of Supabase's 'user' API endpoint when the user is not logged in, so that's not a problem.
I am still getting two API requests to Supabase's auth API when I load the Pricing page. One is from the middleware, and one is from the user API when we conditionally render the page based on whether the user is logged in. So there's still some redundancy there, but it's probably unavoidable, and I think the change to the pattern matcher will mostly resolve the rate-limit problem I was running into.
As far as I'm concerned, this PR is ready to be merged. The only question still to be resolved is how you want to reconcile @dalkommatt's version with mine.

@dijonmusters actually the problem of redundant API calls was much worse than I described above. The Supabase 'auth' API log showed only two calls per page load, but the 'edge' API log showed a lot more than that. When I added a console log in the middleware to see what routes it was being rendered on, the reason for the problem became obvious:

Calling middleware for route:  /
Calling middleware for route:  /vercel.svg
Calling middleware for route:  /nextjs.svg
Calling middleware for route:  /stripe.svg
Calling middleware for route:  /supabase.svg
Calling middleware for route:  /github.svg

Accordingly, I updated the pattern matcher:
export const config = {
  matcher: [
    /*
     * Match all request paths except for the ones starting with:
     * - _next/static (static files)
     * - _next/image (image optimization files)
     * - favicon.ico (favicon file)
     * Feel free to modify this pattern to include more paths.
     */
    '/((?!_next/static|_next/image|favicon.ico|.*\\.(?:svg|png|jpg|jpeg|gif|webp)$).)*',
  ],
}

So that issue, at least, has been resolved. Way fewer edge API calls being logged now. And it looks like the '401: invalid claim: missing sub claim' log entry is just the expected response of Supabase's 'user' API endpoint when the user is not logged in, so that's not a problem.
I am still getting two API requests to Supabase's auth API when I load the Pricing page. One is from the middleware, and one is from the user API when we conditionally render the page based on whether the user is logged in. So there's still some redundancy there, but it's probably unavoidable, and I think the change to the pattern matcher will mostly resolve the rate-limit problem I was running into.
As far as I'm concerned, this PR is ready to be merged. The only question still to be resolved is how you want to reconcile @dalkommatt's version with mine.
(By the way, sorry for taking so long to resolve this. Life's been busy lately!)

Awesome work! I will need to update that pattern in other templates and docs pages too! 🙌
This looks great! I think it's ready to merge!
@dalkommatt are you okay if we merge this one, and then open a separate PR to add anything that's missing? Is it just the magic link option, or have these significantly diverged?

@dijonmusters actually the problem of redundant API calls was much worse than I described above. The Supabase 'auth' API log showed only two calls per page load, but the 'edge' API log showed a lot more than that. When I added a console log in the middleware to see what routes it was being rendered on, the reason for the problem became obvious:

Calling middleware for route:  /
Calling middleware for route:  /vercel.svg
Calling middleware for route:  /nextjs.svg
Calling middleware for route:  /stripe.svg
Calling middleware for route:  /supabase.svg
Calling middleware for route:  /github.svg

Accordingly, I updated the pattern matcher:
export const config = {
  matcher: [
    /*
     * Match all request paths except for the ones starting with:
     * - _next/static (static files)
     * - _next/image (image optimization files)
     * - favicon.ico (favicon file)
     * Feel free to modify this pattern to include more paths.
     */
    '/((?!_next/static|_next/image|favicon.ico|.*\\.(?:svg|png|jpg|jpeg|gif|webp)$).)*',
  ],
}

So that issue, at least, has been resolved. Way fewer edge API calls being logged now. And it looks like the '401: invalid claim: missing sub claim' log entry is just the expected response of Supabase's 'user' API endpoint when the user is not logged in, so that's not a problem.
I am still getting two API requests to Supabase's auth API when I load the Pricing page. One is from the middleware, and one is from the user API when we conditionally render the page based on whether the user is logged in. So there's still some redundancy there, but it's probably unavoidable, and I think the change to the pattern matcher will mostly resolve the rate-limit problem I was running into.
As far as I'm concerned, this PR is ready to be merged. The only question still to be resolved is how you want to reconcile @dalkommatt's version with mine.
(By the way, sorry for taking so long to resolve this. Life's been busy lately!)

Awesome work! I will need to update that pattern in other templates and docs pages too! 🙌
This looks great! I think it's ready to merge!
@dalkommatt are you okay if we merge this one, and then open a separate PR to add anything that's missing? Is it just the magic link option, or have these significantly diverged?

@dijonmusters I say go ahead and merge and then work from a new PR yeah 👍Chris's PR also has password login/reset, right @chriscarrollsmith ?

Password login/reset (which can be turned on or off with a flag) is the main difference, but I've tinkered with lots of other stuff too. Added support for local development with Supabase, moved the API endpoints to server actions, fixed lots of minor bugs, that kind of thing.
I've back-merged all but your latest commit, so the only reconciliation needed will be in how we handle comparing the new and old email when it's changed from the account page. You handled this with an error toast, while I opted to reject the request without one. Also, I believe you handled it server-side, while I handled it on the client.
Other than that commit, I don't think you'll have to resolve a lot of conflicts. (Git might have other ideas, idk.) If you don't want to deal with the git merge, @dijonmusters can just accept the other open PR and close this one. Like I said, I pulled all your changes into it, so you will still get credit for your work.

Oh right! I didn't realise we were talking about two divergent branches. Sounds like there is quite a bit in Chris' PR. @dalkommatt how do you feel about resolving those conflicts and merging that into this branch - would be good to keep this history of conversation with the PR that gets merged. Then @thorwebdev and myself can do one final review and get this mega chunk of awesomeness merged in once and for all! 🎉

@chriscarrollsmith can you also update the matcher pattern from
'/((?!_next/static|_next/image|favicon.ico|.*\\.(?:svg|png|jpg|jpeg|gif|webp)$).)*'

to
'/((?!_next/static|_next/image|favicon.ico|.*\\.(?:svg|png|jpg|jpeg|gif|webp)$).*)'

Just noticed that last star is in the wrong place so it doesn't match any route ever 😬

@chriscarrollsmith can you also update the matcher pattern from
'/((?!_next/static|_next/image|favicon.ico|.*\\.(?:svg|png|jpg|jpeg|gif|webp)$).)*'

to
'/((?!_next/static|_next/image|favicon.ico|.*\\.(?:svg|png|jpg|jpeg|gif|webp)$).*)'

Just noticed that last star is in the wrong place so it doesn't match any route ever 😬

Added a PR to fix this one: https://github.com/dalkommatt/nextjs-subscription-payments/pull/3
Thanks for merging those changes in @dalkommatt 🙌

Another PR to simplify creating a Supabase client server-side, and running prettier over the entire project - sorry for the number of lines changed, but most of them should overlap with the changes in this PR 👍

@dijonmusters @dalkommatt where is supabase.auth.onAuthStateChange listener? When user signs out from one browser window it's basically not redirecting from another windows. Should not we have supabase.auth.onAuthStateChange listener in middleware to log out user from other browser tabs/window.

onAuthStateChange is no longer required for the auth flow as we are doing everything server-side. We are explicitly redirecting after the user signs in in /app/auth/callback/route.ts and after the user signs out in /components/ui/Navbar/Navbar.tsx.
Previously the auth listener was required as it was the only way to know when the authentication process had completed. That is not the case with the code exchange route in the PKCE flow used by the auth-helpers and ssr packages 👍

Have same question as @tmanager2025. How to log out users from all other logged in tabs, when they signed out from one tab. Should not we listen to onAuthStateChange event to do this.

The onAuthStateChange function should work to solve that specific use case, but not sure this problem needs to be solved for this template - every line of code included increases the complexity and maintenance burden for everyone that uses it.
It is pretty common for auth state to be checked on navigation or refresh, so if someone has logged out in a different tab, it should be expected that the app running in another tab is in a different state until they refresh or navigate somewhere that requires authentication.
I would recommend leaving this out of the template, and up to the individual building the app if this is how they want to handle their logout flow 👍

@dijonmusters I agree with @myorgmanager, this is reference for many people for Login and Subscription. Having no way to Logout users on another tabs/window is bad once they logout.
Would love to see have this feature in this PR which is removed and we lost that functionality.
It is important to show how this done with RSC and supabase.

@dijonmusters @dalkommatt @chriscarrollsmith  Any way you could could add the functionality of logging out in other windows/tabs while user logs out from another window in RSC. Would love to see this change also get added as many requested.
Thanks

Just noticed that last star is in the wrong place so it doesn't match any route ever 😬

Added a PR to fix this one: dalkommatt#3
Thanks for merging those changes in @dalkommatt 🙌

Thanks for catching this. Clearly I didn't test enough.

@dijonmusters @dalkommatt @chriscarrollsmith Any way you could add the functionality of logging out in other windows/tabs while user logs out from another window in RSC.
Would love to see this change also get added as many requested.
Thanks

Honestly, this has been open so long, I'd like to just see it get merged. We can work on your issue in a separate PR.

@dijonmusters @dalkommatt @chriscarrollsmith Any way you could add the functionality of logging out in other windows/tabs while user logs out from another window in RSC.
Would love to see this change also get added as many requested.
Thanks

Honestly, this has been open so long, I'd like to just see it get merged. We can work on your issue in a separate PR.

Yep, I agree! Let's move any additional functionality to a separate follow-up PR 👍
@thorwebdev and I will review and test today, if any one else could try the whole flow end-to-end (setting up Stripe etc) that would be super helpful, as these changes are pretty extensive 😬

I just tested this with a new Supabase and a new Stripe account, and it works like a charm — great work y'all 💚

Fuller list of issues and pull requests this PR should close:
Closes https://github.com/vercel/nextjs-subscription-payments/pull/278, closes https://github.com/vercel/nextjs-subscription-payments/pull/262, closes https://github.com/vercel/nextjs-subscription-payments/issues/252, closes https://github.com/vercel/nextjs-subscription-payments/pull/254, closes https://github.com/vercel/nextjs-subscription-payments/pull/249, closes https://github.com/vercel/nextjs-subscription-payments/pull/244, closes https://github.com/vercel/nextjs-subscription-payments/pull/236, closes https://github.com/vercel/nextjs-subscription-payments/pull/222, closes https://github.com/vercel/nextjs-subscription-payments/pull/200, closes https://github.com/vercel/nextjs-subscription-payments/pull/190, closes https://github.com/vercel/nextjs-subscription-payments/pull/115, closes https://github.com/vercel/nextjs-subscription-payments/pull/280, closes https://github.com/vercel/nextjs-subscription-payments/pull/281, closes https://github.com/vercel/nextjs-subscription-payments/pull/284
Fixes https://github.com/vercel/nextjs-subscription-payments/issues/269, fixes https://github.com/vercel/nextjs-subscription-payments/issues/267, fixes https://github.com/vercel/nextjs-subscription-payments/issues/265, fixes https://github.com/vercel/nextjs-subscription-payments/issues/255, fixes https://github.com/vercel/nextjs-subscription-payments/issues/248, fixes https://github.com/vercel/nextjs-subscription-payments/issues/241, fixes https://github.com/vercel/nextjs-subscription-payments/issues/225, fixes https://github.com/vercel/nextjs-subscription-payments/issues/224, fixes https://github.com/vercel/nextjs-subscription-payments/issues/184, fixes https://github.com/vercel/nextjs-subscription-payments/issues/170, fixes https://github.com/vercel/nextjs-subscription-payments/issues/80, fixes https://github.com/vercel/nextjs-subscription-payments/issues/290, fixes https://github.com/vercel/nextjs-subscription-payments/issues/283, fixes https://github.com/vercel/nextjs-subscription-payments/issues/288

Just a note to say that I have been using this PR/branch as a base for a new project without issue. Nice work!!

Testing this out in a new project for my client! It runs SO smoothly 🚀 awesome work y'all!

Awesome work everyone! I think this is ready to merge! 🎉

Just some feedback, while testing this pr. I noticed that after subscribing to a plan and then directly navigating to the homepage, clicking on "manage" in the pricing section allows me to subscribe again to the same plan.

Just some feedback, while testing this pr. I noticed that after subscribing to a plan and then directly navigating to the homepage, clicking on "manage" in the pricing section allows me to subscribe again to the same plan.

Thanks so much for testing! I will see what I can do to fix that bug.

Just some feedback, while testing this pr. I noticed that after subscribing to a plan and then directly navigating to the homepage, clicking on "manage" in the pricing section allows me to subscribe again to the same plan.

Thanks so much for testing! I will see what I can do to fix that bug.

Looks like you can resolve this at the Stripe level now: https://stripe.com/docs/payments/checkout/limit-subscriptions
We could just add a step to the Setting up the customer portal section of the README.
This could either be done in this PR or a future one 👍

Amazing work everyone 💯


Support for OpenAI Retrieval Plug-in

For me, the most useful plug-in will be the open AI retrieval plug-in https://github.com/openai/chatgpt-retrieval-plugin.  Note that by implementing that plug-in it's a small step towards supporting more standard plug-ins.  I'm not sure if people are working on this.  I'm not a big javascript coder, so I will try to hack something in but if someone could work on a more robust implementation that would be cool.

To me, the best aspect of this plugin is the possibility to add memory to the model.
It would be absolutely awesome to have this feature in chatbot-ui!

adding general possibilities for plugins would be cool. I've seen some guy doing it https://github.com/artmatsak/horace

For the record, it would be great if this project had a discussions tab. This seemed the most appropriate place to submit other enhancement ideas. The Chatbot-UI project appears to me to be the best implementation of Chat GPT client, and generally speaking, I love it and use it as my primary GPT4 interface.
Summary of Enhancements and Integrations for chatbot-ui

NextAuth integration: Add login functionality using NextAuth. This practical enhancement can be based on the work done in a similar project. Add GitHub, Google, and Email options to login. Retain anonymous access for demo purposes.

Example implementation: kendevco/aichat
NextAuth Course - Complete Authentication with Credentials, Google & GitHub tutorial](https://www.youtube.com/watch?v=t0Fs0NO78X8)

PineCone document indexing: Allow users to upload documents and use PineCone for indexing them. The mayooear/gpt4-pdf-chatbot-langchain project on GitHub demonstrates this implementation and I found it after watching a no longer available Youtube video describing it.

AutoGPT integration: Incorporate AutoGPT functionality for running multiple agents, spawning agents, etc., external document retrieval, saving files locally, and more. It would be great to see the various agent messages pop into the chat view along with everything else. Several browser-based implementations are available, and it would be cool to have one in this project. A separate tab could be added to manage files used by the agents.

Auto-GPT project: Torantulino/Auto-GPT

alpaca-electron for running LLMs locally: Integrate ItsPi3141/alpaca-electron to run LLMs like Vicuna locally. Alpaca-electron provides a similar UI and shows how to instantiate a large language model locally.

The current implementation lacks chat history chaining.

And thanks for the tip to Horace! This is not intended to be an exhaustive list, but I believe this would be the most versatile tool for working with LLMs and perhaps become the foundation for a new AutoGPT implementation.

This would be the best next steps for chatbot-ui, I second the suggestions.