This is a great feature. Can maintainers of this repo comment on if this can be accepted or maybe offer alternative guidance for handling the issue @timkpaine has raised?

Would echo the previous sentiment, I too would appreciate if the maintainers can comment on Tims' patch.

@jtpio I think this a a good feature, should we consider it for 0.4.0 ?

Echoing the above two comments. Please advise on how I can pass a single string variable to my notebook. I am using voila.app.Voila.start() to create the kernel, per #218 (comment).

Benchmark report

The execution time (in milliseconds) are grouped by test file, test type and browser.
For each case, the following values are computed: min <- [1st quartile - median - 3rd quartile] -> max.

--- /dev/fd/63	2022-07-25 13:04:09.018022201 +0000
+++ /dev/fd/62	2022-07-25 13:04:09.018022201 +0000
@@ -4,37 +4,37 @@
     "BENCHMARK_REFERENCE": "actual"
   },
   "browsers": {
-    "chromium": "97.0.4666.0"
+    "chromium": "94.0.4595.0"
   },
   "systemInformation": {
     "cpu": {
-      "brand": "Xeon® Platinum 8171M",
+      "brand": "Xeon® E5-2673 v3",
       "cache": {
         "l1d": 65536,
         "l1i": 65536,
-        "l2": 2097152,
-        "l3": 36700160
+        "l2": 524288,
+        "l3": 31457280
       },
       "cores": 2,
       "family": "6",
-      "flags": "fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti fsgsbase bmi1 hle avx2 smep bmi2 erms invpcid rtm avx512f avx512dq rdseed adx smap clflushopt avx512cd avx512bw avx512vl xsaveopt xsavec xsaves md_clear",
+      "flags": "fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm invpcid_single pti fsgsbase bmi1 avx2 smep bmi2 erms invpcid xsaveopt md_clear",
       "governor": "",
       "manufacturer": "Intel®",
-      "model": "85",
+      "model": "63",
       "physicalCores": 2,
       "processors": 1,
       "revision": "",
       "socket": "",
-      "speed": 2.6,
+      "speed": 2.4,
       "speedMax": null,
       "speedMin": null,
-      "stepping": "4",
+      "stepping": "2",
       "vendor": "GenuineIntel",
       "virtualization": false,
       "voltage": ""
     },
     "mem": {
-      "total": 7281008640
+      "total": 7291699200
     },
     "osInfo": {
       "arch": "x64",
@@ -42,11 +42,11 @@
       "codename": "Focal Fossa",
       "codepage": "UTF-8",
       "distro": "Ubuntu",
-      "kernel": "5.15.0-1014-azure",
+      "kernel": "5.8.0-1040-azure",
       "logofile": "ubuntu",
       "platform": "linux",
-      "release": "20.04.4 LTS",
-      "serial": "2dc2d73cec5c409b97a391e53a41a4ba",
+      "release": "20.04.3 LTS",
+      "serial": "cfc067bfcb844f35865e279a1b0e66c5",
       "servicepack": "",
       "uefi": false
     }

I am getting this back up and working, is there any specific examples/docs I should add? I no longer have access to how I used this to enable custom token-based authentication at JP Morgan (maybe @vidartf can construct some examples off this) but im planning on adding a simple test to extract a query parameters and run papermill so I can close #484

This PR would solve my needs for authentication in a very clean way. If I want to support auth via authorization token or cookies, I could simply read them via this hook and then mutate a notebook cell to include the authorization information required to make additional client requests.

Edit: Oh, I guess that's exactly how papermill works. Neat.

Well I put the minor fix in a PR here hoping to see the workflows run: #1148
but you need a maintainer to allow the workflows to run if you're a first-time contributor (sensible policy). When you have time, you can apply that commit in this PR or whatever makes the most sense.

I will do it here tonight, apologies

@alkasm I merged your branch into mine, as a weird side effect your PR and my PR are now both running the tests but I think they're the same

Awesome, and no worries on the timeline. I deleted my branch. Thanks for being so responsive on a relatively stale PR!

Wanted to note that this is NOT a breaking change, so does not necessarily need to wait for 4.0.

Yeah it looks like flaky tests, I tried 4-5 times (rebased and force pushed empty commits) and got different tests failing every time

@trungleduc @jtpio @maartenbreddels @martinRenou @davidbrochart ready for review / discussion

Just bumping, I can't sponsor this feature right now with my current employer but I can reveal that a large former employer, J.P. Morgan, uses/used this feature extensively which is a decent endorsement:

https://tim.paine.nyc/talks/jupytercon.html#/5/1/1

Hi @timkpaine, thank you very much for your contribution! I'm quite busy during this period but I will take a look at this PR in a few weeks.
My plan is to target this PR to 0.4.0 in order to facilitate the tracking of new features then we can back-port it to 0.3.x

I've noticed that this only works when you serve a single notebook, e.g. by overriding the notebook_path argument on the voila.app.Voila class or equivalently by passing a positional arg to the voila CLI. If you try to serve a directory of notebooks (e.g. with root_dir on the Voila class or by launching the voila CLI with no positional args), none of the requests get intercepted: neither the request which serves the directory nor the /voila/render/<notebook>.ipynb links provided in the directory view.

edit: I think probably adding it to here is sufficient:

I'll test that out shortly

edit 2: Yeah, that works

Thanks @timkpaine for your contribution, it looks really nice.
I have one question about the hook and preheated kernel mode. In this mode, the notebook is rendered only once, so the hook function is only called once and usually when no user is connected. So any hook that reads the request headers is not usable in preheated kernel mode. How do we inform users about the incompatibility of these two features?

I've noticed that this only works when you serve a single notebook, e.g. by overriding the notebook_path argument on the voila.app.Voila class or equivalently by passing a positional arg to the voila CLI. If you try to serve a directory of notebooks (e.g. with root_dir on the Voila class or by launching the voila CLI with no positional args), none of the requests get intercepted: neither the request which serves the directory nor the /voila/render/<notebook>.ipynb links provided in the directory view.

edit: I think probably adding it to here is sufficient:

voila/voila/app.py

Lines 568 to 573 in e658bbe

	VoilaHandler,
	{
	'template_paths': self.template_paths,
	'config': self.config,
	'voila_configuration': self.voila_configuration
	}),

I'll test that out shortly

edit 2: Yeah, that works

I confirm, the prelaunch_hook does not work with the case of serving a directory.

Thanks @timkpaine for your contribution, it looks really nice.
I have one question about the hook and preheated kernel mode. In this mode, the notebook is rendered only once, so the hook function is only called once and usually when no user is connected. So any hook that reads the request headers is not usable in preheated kernel mode. How do we inform users about the incompatibility of these two features?

That is correct, I can add a note to the documentation. I have long rallied against the preheat mode for this reason: #712 (comment)

I think the documentation for this conflict is not enough, we might need some checks on startup and warn users if they use both features.

Thanks @timkpaine!

thanks @trungleduc ! cc @vidartf @ptomecek

Just updated the milestone to 0.3.x.

According to the diff and the comment above. there doesn't seem to be breaking changes, so this can be shipped in the next 0.3.x release.