text:
jest-runner is not working with even a simple project

Summary
I am trying to include Stryker into a project that uses Jest, but I'm running up against problems with even the simplest of projects. To demonstrate this, I have created a dead-simple node project that uses Jest and generates the following issue:

Repo: https://github.com/tylermurry/stryker-jest-runner-issues-2071

11:12:27 (16352) INFO ConfigReader Using stryker.conf.js in the current working directory.
11:12:28 (16352) WARN InputFileResolver No files marked to be mutated, Stryker will perform a dry-run without actually mutating anything. You can configure the `mutate` property in your stryker.conf.js file (or use `--mutate` via command line).
11:12:28 (16352) INFO InitialTestExecutor Starting initial test run. This may take a while.
11:12:31 (16352) WARN Sandbox Could not symlink "/Users/dev/stryker-test/node_modules" in sandbox directory, it is already created in the sandbox. Please remove the node_modules from your sandbox files. Alternatively, set `symlinkNodeModules` to `false` to disable this warning.
11:12:36 (16352) ERROR InitialTestExecutor One or more tests resulted in an error:
        Test runner crashed. Tried twice to restart it without any luck. Last time the error message was: Error: TypeError: Cannot read property 'runCLI' of undefined
TypeError: Cannot read property 'runCLI' of undefined
    at JestPromiseTestAdapter.run (/Users/dev/stryker-test/node_modules/@stryker-mutator/jest-runner/src/jestTestAdapters/JestPromiseTestAdapter.js:17:31)
    at JestTestRunner.run (/Users/dev/stryker-test/node_modules/@stryker-mutator/jest-runner/src/JestTestRunner.js:43:56)
    at ChildProcessTestRunnerWorker.run (/Users/dev/stryker-test/node_modules/@stryker-mutator/core/src/test-runner/ChildProcessTestRunnerWorker.js:24:56)
    at ChildProcessProxyWorker.doCall (/Users/dev/stryker-test/node_modules/@stryker-mutator/core/src/child-proxy/ChildProcessProxyWorker.js:75:56)
    at resolve (/Users/dev/stryker-test/node_modules/@stryker-mutator/core/src/child-proxy/ChildProcessProxyWorker.js:46:53)
    at new Promise (<anonymous>)
    at ChildProcessProxyWorker.handleMessage (/Users/dev/stryker-test/node_modules/@stryker-mutator/core/src/child-proxy/ChildProcessProxyWorker.js:46:17)
    at process.emit (events.js:198:13)
    at emit (internal/child_process.js:832:12)
    at process._tickCallback (internal/process/next_tick.js:63:19)
Error: TypeError: Cannot read property 'runCLI' of undefined
TypeError: Cannot read property 'runCLI' of undefined
    at JestPromiseTestAdapter.run (/Users/dev/stryker-test/node_modules/@stryker-mutator/jest-runner/src/jestTestAdapters/JestPromiseTestAdapter.js:17:31)
    at JestTestRunner.run (/Users/dev/stryker-test/node_modules/@stryker-mutator/jest-runner/src/JestTestRunner.js:43:56)
    at ChildProcessTestRunnerWorker.run (/Users/dev/stryker-test/node_modules/@stryker-mutator/core/src/test-runner/ChildProcessTestRunnerWorker.js:24:56)
    at ChildProcessProxyWorker.doCall (/Users/dev/stryker-test/node_modules/@stryker-mutator/core/src/child-proxy/ChildProcessProxyWorker.js:75:56)
    at resolve (/Users/dev/stryker-test/node_modules/@stryker-mutator/core/src/child-proxy/ChildProcessProxyWorker.js:46:53)
    at new Promise (<anonymous>)
    at ChildProcessProxyWorker.handleMessage (/Users/dev/stryker-test/node_modules/@stryker-mutator/core/src/child-proxy/ChildProcessProxyWorker.js:46:17)
    at process.emit (events.js:198:13)
    at emit (internal/child_process.js:832:12)
    at process._tickCallback (internal/process/next_tick.js:63:19)
    at ChildProcess.worker.on (/Users/dev/stryker-test/node_modules/@stryker-mutator/core/src/child-proxy/ChildProcessProxy.js:133:68)
    at ChildProcess.emit (events.js:198:13)
    at emit (internal/child_process.js:832:12)
    at process._tickCallback (internal/process/next_tick.js:63:19)
11:12:36 (16352) ERROR StrykerCli an error occurred Error: Something went wrong in the initial test run
    at InitialTestExecutor.validateResult (/Users/dev/stryker-test/node_modules/@stryker-mutator/core/src/process/InitialTestExecutor.js:86:15)
    at InitialTestExecutor.run (/Users/dev/stryker-test/node_modules/@stryker-mutator/core/src/process/InitialTestExecutor.js:41:14)
    at process._tickCallback (internal/process/next_tick.js:68:7)
11:12:36 (16352) INFO StrykerCli Trouble figuring out what went wrong? Try `npx stryker run --fileLogLevel trace --logLevel debug` to get some more info.

Stryker config

module.exports = function(config) {
  config.set({
    mutator: "javascript",
    packageManager: "npm",
    reporters: ["clear-text", "progress"],
    testRunner: "jest",
    transpilers: [],
    coverageAnalysis: "off"
  });
};

Test runner config
None
Stryker environment

├─┬ @stryker-mutator/core@2.5.0
│ ├─┬ @stryker-mutator/api@2.5.0
│ ├── @stryker-mutator/util@2.5.0
├─┬ @stryker-mutator/javascript-mutator@2.5.0
│ ├── @stryker-mutator/api@2.5.0 deduped
├─┬ @stryker-mutator/jest-runner@2.5.0
│ ├── @stryker-mutator/api@2.5.0 deduped

+-- jest@25.1.0

Test runner environment

npm test

Your Environment

software
version(s)

node
10.16.1

npm
6.14.1

Operating System
MacOS 10.14.5

Add stryker.log
stryker.log

Hi! This seems to be a duplicate of #1983
Support for Jest 25 will be released with v3 of Stryker. For now, please downgrade to Jest 24 or wait for v3 of Stryker, sorry!

Hi! Jest 25 support has been released with @stryker-mutator version 3! You can read all about it here: https://stryker-mutator.io/blog/2020-03-11/stryker-version-3

Still not working with versio > 24. I was using jest version 26 I need to downgrade to version 24 to get it working.  Stricker version 3.3.1.

authors: simondel statefull tylermurry

repo: stryker-mutator/stryker


text:
feat(mocha-framework): Move mocha test framework to seperate package

Move mocha test framework to its seperate package. This should prevent confusion about the state of the mocha test framework plugin. It only works with the stryker-mocha-runner test runner plugin at the moment, so it will downgrade coverageAnalysis: 'perTest' to coverageAnalysis: 'all' when another test runner is used.
BREAKING CHANGE: Users with testRunner: "mocha",testFramework: "mocha" should now also install "stryker-mocha-framework".

It seems that travis is having a hard time. At https://www.traviscistatus.com/ I can see:

GitHub Degraded Performance

I will do a push again tomorrow and see if it works again

source: gharchive/pull-request

license_type: permissive

license_source: bigquery


text:
Fix Licensing issues

The Google Play Services API changed and licensing is no longer needed.
I changed the codebase according to commits on this issue .

C'est normal la suppression de licenseLink ?

Hmm pas forcément.
C'est peut-être du code en trop car jai repris ce commit mais celui-ci devrait suffire.
Je ne sais pas si c'est bien grave car licenseLink a disparu du repo principal (le fichier a été renommé en CordovaGoogleMaps.java et à sa création en Septembre 2016, ce bout de code n'était déjà plus là). On n'est cependant pas dans le scope du correctif de base donc je ne sais pas vraiment si c'est grave de virer ça.

Ok je voulais vérifier s'il fallait rajouter le code mais après une bonne relecture, ça a du sens de virer la partie licenseLink du code.
Le problème initial vient de GooglePlayServicesUtil.getOpenSourceSoftwareLicenseInfo() qui n'existe plus.

On supprime ces appels depuis GoogleMaps.java et on se rend compte que le fichier AsyncLicenceInfo.java ne sert à rien sans cet appel.

On supprime ce fichier.

En le supprimant, on refactore GoogleMaps.java.

On supprime alors showLicenseText().

Cette méthode ne servait que lorsqu'on était sur une vue LICENSE_LINK_ID. Cette vue ne sert plus à rien.

On supprime cette vue et les données qui lui étaient propres.

Concrètement, je pense qu'on est bon avec le code comme ça 👍

authors: shajz stubbst

repo: stubbst/cordova-plugin-googlemaps

license_source: github-api


text:
Move from CloudFlare to Heroku SSL w/ Let's Encrypt

Resources

https://blog.heroku.com/ssl-is-now-included-on-all-paid-dynos

Steps

[x] Acquire an SSL certificate from your SSL provider
Upload the certificate to Heroku
Update your DNS settings to reference the new SSL endpoint

Done last week with a wonderful assist from @kevinrobinson.

source: gharchive/issue

repo: studentinsights/studentinsights

license: mit


text:
Fix bug in IEP document branching

Fix bug from https://github.com/studentinsights/studentinsights/pull/2070.

selfie


text:
【翻译完成】20190829-a-look-at-go-1-13-errors -> issue#1403

源issue #1403

ci 没通过，请处理下

repo: studygolang/GCTT


text:
Rotate biscuit key

The current implementation does not rotate the biscuit key

Done


text:
SSR styleSheet returning empty classes

Wanted to try SSR, but i can't get it working, i'm using it with babel-plugin-styled-components with ssr enabled
Version
@next
Steps to reproduce
styleSheet.rules().map(rule => rule.cssText).join('\n')

Expected Behavior
{ cssText: '.g5zuto-0 { backgroundColor: red }' }
{ cssText: '.ndyyfc-1 { padding: 1rem }' }
......

Actual Behavior
{ cssText: '.g5zuto-0 {}' }
{ cssText: '.ndyyfc-0 {}' }
{ cssText: '.ndyyfc-1 {}' }
{ cssText: '.ndyyfc-2 {}' }
{ cssText: '.ndyyfc-3 {}' }
{ cssText: '.ndyyfc-4 {}' }
{ cssText: '.ndyyfc-5 {}' }

The babel plugin only works with v2. Are you using that version?
Also there's now an SSR api: https://github.com/styled-components/styled-components/blob/v2/src/models/StyleSheet.js

Yes im using v2, im at phone will analyze soon, btw is this api final for ssr

@philpl using  styled-components@2.0.0-10 receiving bunch of empty classes
const styles = styleSheet.rules().map(rule => rule.cssText }).join('\n')
console.log(styles)
.a7j1iu-2 {}
.a7j1iu-3 {}
.a7j1iu-4 {}
.a7j1iu-5 {}
.a7j1iu-6 {}
.s1loi16n-0 {}

.babelrc
  "presets": [
    ["es2015", { "modules": false }],
    "react"
  ],
  "plugins": [
    "react-hot-loader/babel",
    "transform-class-properties",
    "transform-object-rest-spread",
    ["styled-components", {
      "ssr": true
    }]
  ]

server code
require('babel-register')
const express = require('express')
const React = require('react')
const ReactDOMServer = require('react-dom/server')
const { StaticRouter } = require('react-router-dom')
const App = require('../src/app').default
const path = require('path')
const Helmet = require('react-helmet')
const styleSheet = require('styled-components/lib/models/StyleSheet')
const compression = require('compression')
const _ = require('lodash')
const { createStore } = require('redux')
const { Provider } = require('react-redux')
const rootReducers = require('../src/store/rootReducers').default

const server = express()
server.use(compression())
server.use('/static', express.static(path.join(__dirname, '../public/static')))

server.use((req, res) => {
  const store = createStore(rootReducers)
  const context = {}
  const body = ReactDOMServer.renderToString(
    React.createElement(StaticRouter, {
      location: req.url,
      context: context
    },
    React.createElement(
      Provider, {
        store: store
      },
      React.createElement(App))
    )
  )

  const styles = styleSheet.rules().map(rule => rule.cssText }).join('\n')
  console.log(styles)

  const seo = Helmet.rewind()
  const html = `
      <!doctype html>
      <html ${seo.htmlAttributes.toString()}>
          <head>
              <meta charset="utf-8" />
              ${seo.title.toString()}
              ${seo.meta.toString()}
              ${seo.link.toString()}
              <link href="https://fonts.googleapis.com/css?family=Open+Sans:300,400,600,700" rel="stylesheet">
              <link rel="stylesheet" href="/static/css/normalize.min.css">
          </head>
          <body>
              <div id="root">
                <%= body %>
              </div>
              <script rel="preload" src="static/js/commons.js"></script>
              <script rel="preload" src="/static/js/bundle.app.js"></script>
          </body>
      </html>
  `
  const makeTemplate = _.template(html)
  if (context.url) {
    res.writeHead(302, {
      Location: context.url
    })
    res.end()
  } else {
    res.send(makeTemplate({body: body}))
    res.end()
  }
})

const PORT = 5050
server.listen(PORT, () => {
  console.log(`Listening http://localhost:5050`)
})

@garmjs Try changing this:
-const styles = styleSheet.rules().map(rule => rule.cssText).join('\n')
+const styles = styleSheet.getCSS()

This, however, doesn't look like the actual issue. The actual issue is this:
const styleSheet = require('styled-components/lib/models/StyleSheet')
This imports the module, but not the bundle that is linked in package.json's main file. So try changing that as well like this:
-const styleSheet = require('styled-components/lib/models/StyleSheet')
+const { styleSheet } = require('styled-components')

@philpl finally got it working 🙏, issue was this with import, thanks a lot 🍻

authors: garmjs philpl

repo: styled-components/styled-components


text:
Cats but not dogs?

I can haz dogs too?

I made a dog faker and a pull request!! Hopefully it gets approved!!

authors: jodygrd wmlutz

repo: stympy/faker


text:
Add a 'Best Practices' tab

Closes #20
@davedelong @subdigital @shawnbierman Please proof-read the content, links etc.
I've been copying and pasting paragraphs while writing to move them over and try to make that section into a nice shape… but I might now have spent too much time on it to be able to focus and see the big picture and if it's readable and well shaped or not

This is what it renders to when I run the server locally, for those of you not used to read in the ~matrix~ HTML code

Oh and last, I think it warrants having your name/Twitter at the bottom there.

This section was contributed by Olivier Halligon

I know the link to the Apple Documentation also links to TN: 1480, but it might be worth explicitly linking to it in the bottom section about en_US_POSIX.
I've also had this conversation recently about ensuring the correct locale is set for API fixed date formats, and one of the recurring questions that cropped up was "what is the bad outcome of not setting the locale?". This is helpful so product, management, or QA know why it's needed and how to validate the solution.
Here's roughly the steps needed to reproduce the issue:
On a device, and it must be on a device, set the region to a European country so the current locale's region will no longer be US (I've only personally validated en_IE, en_ES, and en_DK). After the region is changed, disable 24 hour time by making the clock display 12 hour time with am/pm. Once these changes have taken place on a device, then you are set up for the edge case that is outlined in the Technical Note. If you attempt to parse a date with an hour timestamp greater than 12 hours, the parsing will return nil. For example, parsing 2020-01-15T22:00:00Z will now fail on that device. Only when the formatter uses the fixed local en_US_POSIX, then the device will be able to parse that date correctly.
Feel free to take or leave that example. I'm not sure it's entirely worth adding to the document but I know that question frequently comes up and it can be helpful to point to an example edge case.

This is awesome. Thanks so much! I'll get the site updated soon.

Huuuh I didn't even had time to add a paragraph about the suggestion from Mark above 😅

I'll wait for that then :)

Well you already merged the PR though ^^
I guess we'll need another one then

Follow-up PR in https://github.com/subdigital/nsdateformatter.com/pull/22

authors: AliSoftware marksands subdigital


text:
Run all thumbnailers in an isolated Oz sandbox

Thumbnailers present a significant attack surface for exploitation. The automatically parse (many) binary file formats including obscure formats which are seldom used. The thumbnailers are run automatically on files when their directory is viewed in Nautilus or in another file managers.
It would be good to at least run all of the default thumbnails in an Oz sandbox. I think the Evince is already being run under Oz? It might also be a good idea to disable thumbnailing completely for non-standard format. Who really needs a thumbnail for .pcf fonts or the .cbz comic book format for example?

[ ] evince.thumbnailer
[ ] gnome-font-viewer.thumbnailer

Is there any other default thumbnailers shipped with Subgraph that I'm missing?

I opened this issue in the wrong repo by mistake, https://github.com/subgraph/subgraph-os-issues/issues/241 should be used instead.

repo: subgraph/oz


text:
🛑 Cubari (Dynasty Scans) is down

In 45fc2c4, Cubari (Dynasty Scans) (https://cubari.moe/read/dynasty/the_engagement_of_the_disgraced_witch_and_the_cross_dressing_princess/?cache_buster=$GITHUB_RUN_NUMBER) was down:

HTTP code: 500
Response time: 383 ms

Resolved: Cubari (Dynasty Scans) is back up in 0d88863 after 4 minutes.

repo: subject-f/cubari-status-page

license: MIT


text:
⚠ Guya.moe Proxied has degraded performance

In 8bc1d5e, Guya.moe Proxied (https://ice.guya.moe/) experienced degraded performance:

HTTP code: 200
Response time: 12084 ms

Resolved: Guya.moe Proxied performance has improved in 5c8a71a after 1 hour, 32 minutes.

repo: subject-f/guya-status-page


text:
Create link_google_presentation_open_redirect.yml

Description
New coverage for links to google presentations which contain links to other pages, observed in cred phishing.
Associated samples
Link to samples that are affected by your change.
For example, samples you are negating, samples you are including, or samples your new insight should fire on.

Sample 1
Sample 2

Associated hunts

Hunt 1

/update-test-rules

repo: sublime-security/sublime-rules


text:
Incorrect results when comparing pre-releases

http://semver.org/ states at #11 that,

Precedence for two pre-release versions with the same major, minor, and patch version MUST be determined by comparing each dot separated identifier from left to right until a difference is found as follows: identifiers consisting of only digits are compared numerically and identifiers with letters or hyphens are compared lexically in ASCII sort order. Numeric identifiers always have lower precedence than non-numeric identifiers. A larger set of pre-release fields has a higher precedence than a smaller set, if all of the preceding identifiers are equal. Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0

The results of
var cmp = require('../');
var versions = [
    '1.2.3',
    '1.2.3-alpha',
    '1.0.0-x.7.z.92',
    '1.0.0-alpha.1',
    '1.0.0-alpha',
    '4.11.6',
    '4.2.0',
    '1.5.19',
    '1.5.5',
    '4.1.3',
    '2.3.1',
    '10.5.5',
    '11.3.0',
    '1.0.0',
    '1.0.0-rc.1',
    '1.0.0-beta.11',
    '1.0.0-beta',
    '1.0.0-beta.2',
    '1.0.0-alpha.beta',
    '1.0.0-alpha.1',
    '1.0.0-alpha',
];
console.log(versions.sort(cmp).join('\n'));

are incorrect:
1.0.0-beta.2
1.0.0-alpha
1.0.0-alpha.1
1.0.0-alpha
1.0.0-alpha.1
1.0.0-alpha.beta
1.0.0-x.7.z.92
1.0.0-beta
1.0.0-beta.11
1.0.0-rc.1
1.0.0
1.2.3-alpha
1.2.3
1.5.5
1.5.19
2.3.1
4.1.3
4.2.0
4.11.6
10.5.5
11.3.0

The sorting seems to be unstable:
var cmp = require('../');
var versions = [
    '1.2.3',
    '1.2.3-alpha',
    '1.0.0-x.7.z.92',
    '1.0.0-alpha.1',
    '1.0.0-alpha',
    '4.11.6',
    '11.3.0',
    '1.0.0',
    '1.0.0-rc.1',
    '1.0.0-beta.11',
    '1.0.0-beta',
    '1.0.0-beta.2',
    '1.0.0-alpha.beta',
    '1.0.0-alpha.1',
    '1.0.0-alpha',
];
console.log(versions.sort(cmp).join('\n'));

produces
1.0.0-alpha
1.0.0-x.7.z.92
1.0.0-alpha.1
1.0.0-alpha
1.0.0-alpha.1
1.0.0-alpha.beta
1.0.0-beta.2
1.0.0-rc.1
1.0.0-beta.11
1.0.0-beta
1.0.0
1.2.3-alpha
1.2.3
4.11.6
11.3.0

+1 experiencing the same issue

Me too!

This is a start (still there is an edge case which acts weird, I have no idea why)
function cmpVersions (a, b) {
    // split by pre-releases
    a = a.split('-');
    b = b.split('-');
    a[1] = a[1] || '';
    b[1] = b[1] || '';

    if( a == b ) return 0;

    var i, na, nb,
        pa = a[0].split('.'),
        pb = b[0].split('.');

    for (i = 0; i < 3; i++ ) {
        na = +pa[i];
        nb = +pb[i];
        if (a[1] || b[1]) return b[1].localeCompare(a[1]); //diffrent pre-release string
        if (na > nb) return 1;
        if (nb > na) return -1;
        if (!isNaN(na) && isNaN(nb)) return 1;
        if (isNaN(na) && !isNaN(nb)) return -1;

    }

    return 0;
}

/* TESTS */
var versions = [
    '1.2.3',
    '1.2.3-alpha',
    '1.0.0-x.7.z.92',
    '1.0.0-alpha.1',
    '1.0.0-alpha',
    '4.11.6',
    '4.2.0',
    '1.5.19',
    '1.5.5',
    '4.1.3',
    '2.3.1',
    '10.5.5',
    '11.3.0',
    '1.0.0',
    '1.0.0-rc.1',
    '1.0.0-beta.11',
    '1.0.0-beta',
    '1.0.0-beta.2',
    '1.0.0-alpha.beta',
    '1.0.0-alpha.1',
    '1.0.0-alpha',
];

console.log( versions.sort(cmpVersions).join('\n') );

Here's my solution.
// Copy-pasted from:
// https://github.com/substack/semver-compare/blob/master/index.js
//
// Inlining this function because some users reported issues with
// importing from `semver-compare` in a browser with ES6 "native" modules.
//
// Fixes `semver-compare` not being able to compare versions with alpha/beta/etc "tags".
// https://github.com/catamphetamine/libphonenumber-js/issues/381
export default function(a, b) {
    a = a.split('-')
    b = b.split('-')
    var pa = a[0].split('.')
    var pb = b[0].split('.')
    for (var i = 0; i < 3; i++) {
        var na = Number(pa[i])
        var nb = Number(pb[i])
        if (na > nb) return 1
        if (nb > na) return -1
        if (!isNaN(na) && isNaN(nb)) return 1
        if (isNaN(na) && !isNaN(nb)) return -1
    }
    if (a[1] && b[1]) {
        return a[1] > b[1] ? 1 : (a[1] < b[1] ? -1 : 0)
    }
    return !a[1] && b[1] ? 1 : (a[1] && !b[1] ? -1 : 0)
}

import semverCompare from './semver-compare'

describe('semver-compare', () => {
	it('should compare versions', () => {
		const versions = [
			'1.2.3',
			'4.11.6',
			'4.2.0',
			'1.5.19',
			'1.5.6',
			'1.5.4',
			'1.5.5-alpha.beta',
			'1.5.5-alpha',
			'1.5.5',
			'1.5.5-rc.1',
			'1.5.5-beta.0',
			'4.1.3',
			'2.3.1',
			'10.5.5',
			'11.3.0'
		]
		versions.sort(semverCompare).should.deep.equal([
			'1.2.3',
			'1.5.4',
			'1.5.5-alpha',
			'1.5.5-alpha.beta',
			'1.5.5-beta.0',
			'1.5.5-rc.1',
			'1.5.5',
			'1.5.6',
			'1.5.19',
			'2.3.1',
			'4.1.3',
			'4.2.0',
			'4.11.6',
			'10.5.5',
			'11.3.0'
		])
	})
})

Is used in libphonenumber-js.

authors: JSteunou adius catamphetamine dandv yairEO

repo: substack/semver-compare


text:
Update browserify

Fixes https://github.com/substack/watchify/issues/243

published as watchify@3.3.0

repo: substack/watchify


text:
Don't show empty lists of refs

Currently if there is no references we are rendering empty list (see file reference example), there should be some phrase like there is no file references or action instead.

It was a regression.

repo: substance/texture


text:
Question 2 to 10 are not in correct order.

In Readme file, The sequence of Quetion 2 to 10 are not in correct order.
for ex. Question no. 2: What are the major features of React?
and in answer it shows Answer no. 3.
It will be the same upto Question 10.
There are Two answers under 10 number.

@chetannada  Thanks for creating the PR. Please check my comment in PR

authors: chetannada sudheerj

repo: sudheerj/reactjs-interview-questions


text:
contribution section in readme

Added Contribution section in README. Solves https://github.com/sudz123/Happy_Hacking/issues/48

We already have those details.


text:
Rails 4 compatibility

This doesn't force to ActiveSupport 4 yet, but allows it.   After conferring with @cbeer, we nixed ruby 1.8 support.  If you look at the other dependencies, including redcarpet, we never had 1.8 support anyway.

Changes Unknown when pulling cc6c9ee660a665f9c14ae84410db68c955fbcaa3 on develop into ** on master**.

better late than never, @coveralls?

authors: atz coveralls jmartin-sul

repo: sul-dlss/dor-workflow-service


text:
Determine DAG strategy for Data Exports

Determine how to structure one or more DAGs to support Data export flows. For example, one option would have a scheduled DAG that exported MARC records and then have the DAG trigger specific DAGs for OCLC, POD, and ShareVDE.

Done and in development.

authors: jermnelson jgreben

repo: sul-dlss/libsys-airflow


text:
Front end in dev mode requires SuluAdminBundle

Not sure why this happens, but it happens only in dev mode. Prod mode in website.php works just fine.
I tried clearing the cache, with and without warmup.

Hm, that's really strange... It looks to me like it loads the routing file app/config/admin/routing.yml instead of app/config/website/routing.yml, can you check that?

I tried, but cannot figure out where to check this.
If it helps, here's a full screenshot of the situation with debug mode on: https://drive.google.com/file/d/0BxDWUuqQgPlqWE5Md1BSbTlsNjg/view?usp=sharing

Under which URL are you accessing the website? Are maybe the rewrites defined in web/.htaccess not applied?

I don't use .htaccess, I'm on Nginx. So admin works in both dev and prod, but website works only in prod mode.

Running out of ideas... I think it's easier if I try to get your vagrant box running, and try to figure it out on my own.

Agreed. Let me know if you get stuck, but the procedure should be simple enough.

@Swader do you have your project on a public github repo somewhere? Some configuration file is getting loaded incorrectly somewhere - for website.php, the app/config/website/routing.yml should be loaded - but it looks like app/config/admin/routing.yml is being loaded, but I don't see why (it doesn't happen for me locally).
I'd love to see a bit less configuration in general in Sulu - with the 2 kernels (which is a cool idea), it ends up that there are a lot of configuration files to look at. The MicroKernel in Symfony 2.8 (https://github.com/symfony/symfony/pull/15990) might help, as you could move a lot of the logic of which files to load into the kernels themselves as simple if statements, instead of having one config file load another one, etc (which works nicely, but becomes less clear when you start having many configuration files).

Project is sulu-standard really, just tweaked for performance on Vagrant. Only different is forcing dev mode in website.php rather than prod:
defined('SYMFONY_ENV') || define('SYMFONY_ENV', getenv('SYMFONY_ENV') ?: 'dev');

If you follow the procedure here you'll get to the same point, but really, it's the standard sulu install (all differences described in that post). There's also another aspect of this same bug (presumably) in #553

@weaverryan You are right... I am also struggling with this configuration from time to time... This micro kernel sounds interesting, but I couldn't find any documentation, is that still missing?

Update: problem avoided by forcing the SYMFONY_DEBUG constant to be false, or by simply passing false instead of the constant as the second param of WebsiteKernel. Unclear on why this happens.
Fix suggestion: make it easy to know what needs to be done to activate dev mode. This is something that's not exactly clear in other Symfony apps either - there's many constants and settings that can be tweaked, each depending one on the other. Perhaps a config value for "env-mode" would help. This confusion is why my way of activating dev mode (see my reply to @weaverryan above) did not work.

@Swader What do you think a better way might be? Perhaps a .env file that - at the very least - holds something like SYMFONY_ENV and SYMFONY_DEBUG flags?
Also, your post has some really interesting things to get the VM to run quickly, some things I hadn't thought of before. Also, there are a few parts where there may be a simpler way (e.g. the autoloading speedup) - I'm going to look at that and get back to you if that's ok. I tried yesterday, but conference internet kept the homestead-improved image out of my grasp :).

@Swader I've already written that to you, but I also put it in here so that every interested can see that. The problem was that there is an error when redefining the cache dir as explained in your article. Because of this both kernels used the same cache, which can't work.

Argh, totally ignored that cache context thing, will fix, thanks! But... does that mean prod mode doesn't use cache? I mean, why does it work in prod mode?
@weaverryan definitely, get back to me on that, looking to speed things up as much as possible. Also looking to streamline the vendorfix shell script into something more reusable across standard ZF / Symfony apps (those two FWs are the biggest IO offenders and suffer the most when using shared folders).

Actually it does, I think it depends on which kernel is called first. If the AdminKernel is called first it might also not be a problem, since it contains all the bundle the WebsiteKernel needs as well. But I suppose the behavior when two kernel share caches is always unpredictable.

Mmm, indeed.
Okay, altered the article and tested context specific cache, works like a charm now. Thanks @danrot for taking the time to take a look - I wish I hadn't applied that fix first, would have been easier to avoid all problems if I hadn't left that in. Closing this, and this also closes #553

@danrot No docs on the MicroKernel yet - it just got merged. But it'll be there in the next few weeks, before 2.8 gets released. I think it would be a pretty straightforward thing to implement, just to help the configuration loading be a bit more clear :)

@Swader I am happy to help :smiley:
@weaverryan I have created a separate issue for your MicroKernel suggestion: https://github.com/sulu-io/sulu/issues/1757

authors: Swader danrot weaverryan

repo: sulu-io/sulu-standard


text:
Add intl_alpha3_countries, intl_alpha3_languages functions and Symfony 5 compatibility

Add new Symfony 4.4/5.0 Intl alpha3 functions.
{{ intl_alpha3_country('DEU') }} {# Germany #}
{{ intl_alpha3_language('deu') }} {# German #}

@luca-rath fixed

repo: sulu/web-twig


text:
Controller fails to delete unregistered runner resources

Hello,
Thank you for the project I ran into some problems when I tried to use a custom image for the runner as my use case requires it. Here is what I added:
kind: Runner
metadata:
  name: testrepoansible-runner
spec:
  image: custom_container
  repository: testrepoansible
  env: []

I did this with 2 different containers, one had a typo and failed during pulling. The other did not have a github actions runner installed at all. The idea was to check if someone makes a mistake and adds a resource that does not exist what happens.
Running kubectl delete runner testrepoansible-runner , resource deleted, but the runner was still there. I checked the code and correct me if I am wrong but if the runner does not unregister it cannot be deleted. Here is the error from the controller:
github.com/go-logr/zapr.(*zapLogger).Error
	/go/pkg/mod/github.com/go-logr/zapr@v0.1.0/zapr.go:128
github.com/summerwind/actions-runner-controller/controllers.(*RunnerReconciler).Reconcile
	/workspace/controllers/runner_controller.go:100
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler
	/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.4.0/pkg/internal/controller/controller.go:256
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
	/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.4.0/pkg/internal/controller/controller.go:232
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).worker
	/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.4.0/pkg/internal/controller/controller.go:211
k8s.io/apimachinery/pkg/util/wait.JitterUntil.func1
	/go/pkg/mod/k8s.io/apimachinery@v0.0.0-20190913080033-27d36303b655/pkg/util/wait/wait.go:152
k8s.io/apimachinery/pkg/util/wait.JitterUntil
	/go/pkg/mod/k8s.io/apimachinery@v0.0.0-20190913080033-27d36303b655/pkg/util/wait/wait.go:153
k8s.io/apimachinery/pkg/util/wait.Until
	/go/pkg/mod/k8s.io/apimachinery@v0.0.0-20190913080033-27d36303b655/pkg/util/wait/wait.go:88
2020-03-19T11:51:06.185Z	ERROR	controller-runtime.controller	Reconciler error	{"controller": "runner", "request": "default/example-github-actions-runner", "error": "json: cannot unmarshal object into Go value of type []controllers.GitHubRunner"}
github.com/go-logr/zapr.(*zapLogger).Error
	/go/pkg/mod/github.com/go-logr/zapr@v0.1.0/zapr.go:128
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler
	/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.4.0/pkg/internal/controller/controller.go:258
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
	/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.4.0/pkg/internal/controller/controller.go:232
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).worker
	/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.4.0/pkg/internal/controller/controller.go:211
k8s.io/apimachinery/pkg/util/wait.JitterUntil.func1
	/go/pkg/mod/k8s.io/apimachinery@v0.0.0-20190913080033-27d36303b655/pkg/util/wait/wait.go:152
k8s.io/apimachinery/pkg/util/wait.JitterUntil
	/go/pkg/mod/k8s.io/apimachinery@v0.0.0-20190913080033-27d36303b655/pkg/util/wait/wait.go:153
k8s.io/apimachinery/pkg/util/wait.Until
	/go/pkg/mod/k8s.io/apimachinery@v0.0.0-20190913080033-27d36303b655/pkg/util/wait/wait.go:88

To remove the resource I had to patch the runner:
kubectl patch runner example-github-actions-runner -p '{"metadata":{"finalizers":[]}}' --type=merge

@boris-stoyanov Hey! Thanks for reporting. I believe this is a duplicate of #11 which should be fixed via #7.
Would you mind giving v0.4.0 a try which will be released shortly?

Other than the scary long CRD everything is working fine with the new release.

authors: boris-stoyanov mumoshu

repo: summerwind/actions-runner-controller


text:
h2spec http2/3.5 test 2 should accept a cleartext HTTP/1.1 response if not TLS

h2spec http2/3.5 test 2 should accept a cleartext HTTP/1.1 response if not TLS
3.5. HTTP/2 Connection Preface
      × 2: Sends invalid connection preface
        -> The endpoint MUST terminate the TCP connection.
           Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR)
                     Connection closed
             Actual: Error: unexpected EOF

If h2spec is connecting over cleartext (not TLS) and sends an invalid Connection Preface, then the server may respond with HTTP/1.1 400 Bad Request.  The cleartext scenario is different than a TLS connection over which "h2" was negotiated via ALPN.  In the TLS scenario, the server must send an HTTP/2 GOAWAY, which is what h2spec http2/3.5 test 2 currently expects, and is correct for the TLS scenario.

Duplicates #112


text:
Improvement: Cast back to original/previous type at the end of the scope

In the following bit of code, on line 55 I perform a cast inside an if scope, then call a function on line 56 that takes that type. Later, on line 60, the cast is still in effect, so there is no warning on the argument type for that function call.
On the right side, I do the same cast at the start of the if scope, and cast it back to the original type at the end of the scope (line 57). When I try to call the same function outside of the scope, there's a warning on the argument type, as expected.
For ease of use and type safety, it would be great if I didn't have to perform that cast on line 57, and the server assumed the original/previous type was in effect. If this were the case, I would only have to cast on line 55, after I've made sure the variable is of that type, without having to worry about casting back to the original type.
In short, the editor should behave as shown on the left side, except it should give the warning on line 60 on the right side.
Screenshots

Environment:

OS: Windows
Is WSL remote? No
Client: VSCode

After testing, it has been fixed in a commit of master.

authors: sumneko tonebacas

repo: sumneko/lua-language-server


text:
v3.5.4 格式化代码块，会将代码块后的代码全部删除

How are you using the lua-language-server?
Visual Studio Code Extension (sumneko.lua)
Which OS are you using?
Windows
What is the issue affecting?
Formatting
Expected Behaviour
正确格式化
Actual Behaviour
如题
Reproduction steps

Go to '...'
Click '...'
See error '...'

Additional Notes
No response
Log File
[10:05:15.832][info] [#0:c:\Users\Administrator\.vscode\extensions\sumneko.lua-3.5.4-win32-x64\server\main.lua:65]: Lua Lsp startup, root: 	c:/Users/Administrator/.vscode/extensions/sumneko.lua-3.5.4-win32-x64/server
[10:05:15.832][info] [#0:c:\Users\Administrator\.vscode\extensions\sumneko.lua-3.5.4-win32-x64\server\main.lua:66]: ROOT:	c:/Users/Administrator/.vscode/extensions/sumneko.lua-3.5.4-win32-x64/server
[10:05:15.832][info] [#0:c:\Users\Administrator\.vscode\extensions\sumneko.lua-3.5.4-win32-x64\server\main.lua:67]: LOGPATH:	c:/Users/Administrator/.vscode/extensions/sumneko.lua-3.5.4-win32-x64/server/log
[10:05:15.832][info] [#0:c:\Users\Administrator\.vscode\extensions\sumneko.lua-3.5.4-win32-x64\server\main.lua:68]: METAPATH:	c:/Users/Administrator/.vscode/extensions/sumneko.lua-3.5.4-win32-x64/server/meta
[10:05:15.832][info] [#0:c:\Users\Administrator\.vscode\extensions\sumneko.lua-3.5.4-win32-x64\server\main.lua:69]: VERSION:	3.5.4
[10:05:15.863][info] [#0:script\service\service.lua:141]:
========= Medical Examination Report =========
    --------------- Memory ---------------
        Total: 1.457 MB
        # 00 : 1.457 MB
        # 01 : 0.000 MB
        # 02 : 0.000 MB
        # 03 : 0.000 MB
        # 04 : 0.000 MB
    --------------- Coroutine ---------------
        Total:     0
        Running:   0
        Suspended: 0
        Normal:    0
        Dead:      0
    --------------- Cache ---------------
        Total: 1
        Dead:  0
    ---------------  RPC  ---------------
        Holdon:   0
        Waiting:  0
==============================================
[10:05:16.175][info] [#0:script\language.lua:137]: VSC language: en
[10:05:16.175][info] [#0:script\language.lua:138]: LS  language: en-us
[10:05:16.175][info] [#0:script\workspace\workspace.lua:38]: Workspace init root: 	file:///d%3A/LegendGameJZ/game/runtime/gameclient/src
[10:05:16.175][info] [#0:script\workspace\workspace.lua:42]: Log path: 	c:/Users/Administrator/.vscode/extensions/sumneko.lua-3.5.4-win32-x64/server/log/file_d%3A_LegendGameJZ_game_runtime_gameclient_src.log
[10:05:16.207][info] [#0:script\workspace\workspace.lua:51]: Workspace create: 	file:///d%3A/LegendGameJZ/game/runtime/gameclient/src
[10:05:16.207][info] [#0:script\workspace\workspace.lua:51]: Workspace create: 	file:///d%3A/LegendGameJZ/game/data/long
[10:05:16.409][info] [#0:script\provider\provider.lua:41]: Load config from client	file:///d%3A/LegendGameJZ/game/runtime/gameclient/src
[10:05:16.409][info] [#0:script\provider\provider.lua:42]: {
  Lua = {
    completion = {
      autoRequire = true,
      callSnippet = "Both",
      displayContext = 0,
      enable = true,
      keywordSnippet = "Both",
      postfix = "@",
      requireSeparator = ".",
      showParams = true,
      showWord = "Fallback",
      workspaceWord = true
    },
    diagnostics = {
      disable = {},
      disableScheme = { "git" },
      enable = false,
      globals = {},
      groupFileStatus = {},
      groupSeverity = {},
      ignoredFiles = "Opened",
      libraryFiles = "Opened",
      neededFileStatus = {},
      severity = {},
      unusedLocalExclude = {},
      workspaceDelay = 3000,
      workspaceRate = 100
    },
    format = {
      defaultConfig = {},
      enable = true
    },
    hint = {
      arrayIndex = "Auto",
      await = true,
      enable = true,
      paramName = false,
      paramType = false,
      semicolon = "SameLine",
      setType = false
    },
    hover = {
      enable = true,
      enumsLimit = 5,
      expandAlias = true,
      previewFields = 50,
      viewNumber = true,
      viewString = true,
      viewStringMax = 1000
    },
    misc = {
      parameters = {}
    },
    runtime = {
      builtin = {},
      fileEncoding = "utf8",
      meta = "${version} ${language} ${encoding}",
      nonstandardSymbol = {},
      path = { "?.lua", "?/init.lua", "?/?.lua", "src/?.lua" },
      pathStrict = false,
      plugin = "",
      pluginArgs = {},
      special = {
        ['"reload"'] = "require"
      },
      unicodeName = false,
      version = "Lua 5.1"
    },
    semantic = {
      annotation = true,
      enable = true,
      keyword = false,
      variable = true
    },
    signatureHelp = {
      enable = true
    },
    spell = {
      dict = {}
    },
    telemetry = {
      enable = false
    },
    type = {
      castNumberToInteger = true,
      weakNilCheck = false,
      weakUnionCheck = false
    },
    typeFormat = {
      config = {}
    },
    window = {
      progressBar = true,
      statusBar = true
    },
    workspace = {
      checkThirdParty = false,
      ignoreDir = { ".vscode" },
      ignoreSubmodules = true,
      library = {},
      maxPreload = 5000,
      preloadFileSize = 10000,
      supportScheme = { "file", "untitled", "git" },
      useGitIgnore = true,
      userThirdParty = {}
    }
  },
  ["editor.acceptSuggestionOnEnter"] = "on",
  ["editor.semanticHighlighting.enabled"] = true,
  ["files.associations"] = {},
  ["files.exclude"] = {
    ["**/.DS_Store"] = true,
    ["**/.classpath"] = true,
    ["**/.factorypath"] = true,
    ["**/.git"] = true,
    ["**/.hg"] = true,
    ["**/.project"] = true,
    ["**/.settings"] = true,
    ["**/.svn"] = true,
    ["**/CVS"] = true,
    ["**/Thumbs.db"] = true
  }
}
[10:05:16.503][info] [#0:script\provider\provider.lua:41]: Load config from client	file:///d%3A/LegendGameJZ/game/data/long
[10:05:16.503][info] [#0:script\provider\provider.lua:42]: {
  Lua = {
    completion = {
      autoRequire = true,
      callSnippet = "Both",
      displayContext = 0,
      enable = true,
      keywordSnippet = "Both",
      postfix = "@",
      requireSeparator = ".",
      showParams = true,
      showWord = "Fallback",
      workspaceWord = true
    },
    diagnostics = {
      disable = {},
      disableScheme = { "git" },
      enable = false,
      globals = {},
      groupFileStatus = {},
      groupSeverity = {},
      ignoredFiles = "Opened",
      libraryFiles = "Opened",
      neededFileStatus = {},
      severity = {},
      unusedLocalExclude = {},
      workspaceDelay = 3000,
      workspaceRate = 100
    },
    format = {
      defaultConfig = {},
      enable = true
    },
    hint = {
      arrayIndex = "Auto",
      await = true,
      enable = true,
      paramName = false,
      paramType = false,
      semicolon = "SameLine",
      setType = false
    },
    hover = {
      enable = true,
      enumsLimit = 5,
      expandAlias = true,
      previewFields = 50,
      viewNumber = true,
      viewString = true,
      viewStringMax = 1000
    },
    misc = {
      parameters = {}
    },
    runtime = {
      builtin = {},
      fileEncoding = "utf8",
      meta = "${version} ${language} ${encoding}",
      nonstandardSymbol = {},
      path = { "?.lua", "?/init.lua", "?/?.lua", "src/?.lua" },
      pathStrict = false,
      plugin = "",
      pluginArgs = {},
      special = {
        ['"reload"'] = "require"
      },
      unicodeName = false,
      version = "Lua 5.1"
    },
    semantic = {
      annotation = true,
      enable = true,
      keyword = false,
      variable = true
    },
    signatureHelp = {
      enable = true
    },
    spell = {
      dict = {}
    },
    telemetry = {
      enable = false
    },
    type = {
      castNumberToInteger = true,
      weakNilCheck = false,
      weakUnionCheck = false
    },
    typeFormat = {
      config = {}
    },
    window = {
      progressBar = true,
      statusBar = true
    },
    workspace = {
      checkThirdParty = false,
      ignoreDir = { ".vscode" },
      ignoreSubmodules = true,
      library = {},
      maxPreload = 5000,
      preloadFileSize = 10000,
      supportScheme = { "file", "untitled", "git" },
      useGitIgnore = true,
      userThirdParty = {}
    }
  },
  ["editor.acceptSuggestionOnEnter"] = "on",
  ["editor.semanticHighlighting.enabled"] = true,
  ["files.associations"] = {},
  ["files.exclude"] = {
    ["**/.DS_Store"] = true,
    ["**/.classpath"] = true,
    ["**/.factorypath"] = true,
    ["**/.git"] = true,
    ["**/.hg"] = true,
    ["**/.project"] = true,
    ["**/.settings"] = true,
    ["**/.svn"] = true,
    ["**/CVS"] = true,
    ["**/Thumbs.db"] = true
  }
}
[10:05:16.612][info] [#0:script\provider\provider.lua:56]: Load config from client	fallback
[10:05:16.612][info] [#0:script\provider\provider.lua:57]: {
  Lua = {
    completion = {
      autoRequire = true,
      callSnippet = "Both",
      displayContext = 0,
      enable = true,
      keywordSnippet = "Both",
      postfix = "@",
      requireSeparator = ".",
      showParams = true,
      showWord = "Fallback",
      workspaceWord = true
    },
    diagnostics = {
      disable = {},
      disableScheme = { "git" },
      enable = false,
      globals = {},
      groupFileStatus = {},
      groupSeverity = {},
      ignoredFiles = "Opened",
      libraryFiles = "Opened",
      neededFileStatus = {},
      severity = {},
      unusedLocalExclude = {},
      workspaceDelay = 3000,
      workspaceRate = 100
    },
    format = {
      defaultConfig = {},
      enable = true
    },
    hint = {
      arrayIndex = "Auto",
      await = true,
      enable = true,
      paramName = false,
      paramType = false,
      semicolon = "SameLine",
      setType = false
    },
    hover = {
      enable = true,
      enumsLimit = 5,
      expandAlias = true,
      previewFields = 50,
      viewNumber = true,
      viewString = true,
      viewStringMax = 1000
    },
    misc = {
      parameters = {}
    },
    runtime = {
      builtin = {},
      fileEncoding = "utf8",
      meta = "${version} ${language} ${encoding}",
      nonstandardSymbol = {},
      path = { "?.lua", "?/init.lua", "?/?.lua", "src/?.lua" },
      pathStrict = false,
      plugin = "",
      pluginArgs = {},
      special = {
        ['"reload"'] = "require"
      },
      unicodeName = false,
      version = "Lua 5.1"
    },
    semantic = {
      annotation = true,
      enable = true,
      keyword = false,
      variable = true
    },
    signatureHelp = {
      enable = true
    },
    spell = {
      dict = {}
    },
    telemetry = {
      enable = false
    },
    type = {
      castNumberToInteger = true,
      weakNilCheck = false,
      weakUnionCheck = false
    },
    typeFormat = {
      config = {}
    },
    window = {
      progressBar = true,
      statusBar = true
    },
    workspace = {
      checkThirdParty = false,
      ignoreDir = { ".vscode" },
      ignoreSubmodules = true,
      library = {},
      maxPreload = 5000,
      preloadFileSize = 10000,
      supportScheme = { "file", "untitled", "git" },
      useGitIgnore = true,
      userThirdParty = {}
    }
  },
  ["editor.acceptSuggestionOnEnter"] = "on",
  ["editor.semanticHighlighting.enabled"] = true,
  ["files.associations"] = {},
  ["files.exclude"] = {
    ["**/.DS_Store"] = true,
    ["**/.classpath"] = true,
    ["**/.factorypath"] = true,
    ["**/.git"] = true,
    ["**/.hg"] = true,
    ["**/.project"] = true,
    ["**/.settings"] = true,
    ["**/.svn"] = true,
    ["**/CVS"] = true,
    ["**/Thumbs.db"] = true
  }
}
[10:05:16.612][info] [#0:script\library.lua:207]: Init builtin library at:	file:///d%3A/LegendGameJZ/game/runtime/gameclient/src
[10:05:16.628][info] [#0:script\plugin.lua:86]: plugin path:	D:\LegendGameJZ\game\runtime\gameclient\src
[10:05:16.628][warn] [#0:script\plugin.lua:101]: plugin not found:	D:\LegendGameJZ\game\runtime\gameclient\src
[10:05:16.628][info] [#0:script\library.lua:207]: Init builtin library at:	file:///d%3A/LegendGameJZ/game/data/long
[10:05:16.643][info] [#0:script\plugin.lua:86]: plugin path:	D:\LegendGameJZ\game\data\long
[10:05:16.643][warn] [#0:script\plugin.lua:101]: plugin not found:	D:\LegendGameJZ\game\data\long
[10:05:16.643][info] [#0:script\library.lua:207]: Init builtin library at:	nil
[10:05:16.643][info] [#0:script\provider\completion.lua:43]: Enable completion.
[10:05:16.643][info] [#0:script\workspace\workspace.lua:305]: Preload start:	file:///d%3A/LegendGameJZ/game/runtime/gameclient/src
[10:05:16.659][info] [#0:script\workspace\workspace.lua:311]: Scan files at:	file:///d%3A/LegendGameJZ/game/runtime/gameclient/src
[10:05:16.659][info] [#0:script\workspace\workspace.lua:305]: Preload start:	file:///d%3A/LegendGameJZ/game/data/long
[10:05:16.659][info] [#0:script\workspace\workspace.lua:311]: Scan files at:	file:///d%3A/LegendGameJZ/game/data/long
[10:05:16.659][info] [#0:script\workspace\workspace.lua:305]: Preload start:	<fallback>
[10:05:16.659][info] [#0:script\workspace\workspace.lua:328]: Scan library at:	file:///c%3A/Users/Administrator/.vscode/extensions/sumneko.lua-3.5.4-win32-x64/server/meta/Lua%205.1%20en-us%20utf8
[10:05:16.815][info] [#0:script\workspace\workspace.lua:328]: Scan library at:	file:///c%3A/Users/Administrator/.vscode/extensions/sumneko.lua-3.5.4-win32-x64/server/meta/Lua%205.1%20en-us%20utf8
[10:05:16.831][info] [#0:script\workspace\workspace.lua:328]: Scan library at:	file:///c%3A/Users/Administrator/.vscode/extensions/sumneko.lua-3.5.4-win32-x64/server/meta/Lua%205.1%20en-us%20utf8
[10:05:16.831][info] [#0:script\workspace\workspace.lua:348]: Found 10 files at:	<fallback>
[10:05:16.831][info] [#0:script\workspace\loading.lua:153]: Load files from disk:	<fallback>
[10:05:16.831][info] [#0:script\workspace\workspace.lua:348]: Found 493 files at:	file:///d%3A/LegendGameJZ/game/runtime/gameclient/src
[10:05:16.831][info] [#0:script\workspace\loading.lua:153]: Load files from disk:	file:///d%3A/LegendGameJZ/game/runtime/gameclient/src
[10:05:16.831][info] [#0:script\workspace\workspace.lua:348]: Found 393 files at:	file:///d%3A/LegendGameJZ/game/data/long
[10:05:16.831][info] [#0:script\workspace\loading.lua:153]: Load files from disk:	file:///d%3A/LegendGameJZ/game/data/long
[10:05:17.860][warn] [#0:script\files.lua:532]: Compile [file:///d%3A/LegendGameJZ/game/runtime/gameclient/src/app/data/itemattr.lua] takes [0.369] sec, size [752.067] kb.
[10:05:18.032][warn] [#0:script\files.lua:544]: Parse LuaDoc of [file:///d%3A/LegendGameJZ/game/runtime/gameclient/src/app/data/itemattr.lua] takes [0.182] sec, size [752.067] kb.
[10:05:18.453][warn] [#0:script\files.lua:532]: Compile [file:///d%3A/LegendGameJZ/game/runtime/gameclient/src/app/data/mapinfo.lua] takes [0.227] sec, size [559.045] kb.
[10:05:18.562][warn] [#0:script\files.lua:544]: Parse LuaDoc of [file:///d%3A/LegendGameJZ/game/runtime/gameclient/src/app/data/mapinfo.lua] takes [0.110] sec, size [559.045] kb.
[10:05:18.874][warn] [#0:script\files.lua:532]: Compile [file:///d%3A/LegendGameJZ/game/runtime/gameclient/src/app/data/mondef.lua] takes [0.305] sec, size [921.066] kb.
[10:05:19.015][warn] [#0:script\files.lua:544]: Parse LuaDoc of [file:///d%3A/LegendGameJZ/game/runtime/gameclient/src/app/data/mondef.lua] takes [0.136] sec, size [921.066] kb.
[10:05:20.060][warn] [#0:script\files.lua:532]: Compile [file:///d%3A/LegendGameJZ/game/runtime/gameclient/src/app/data/itemdef.lua] takes [1.039] sec, size [2505.223] kb.
[10:05:20.434][warn] [#0:script\files.lua:544]: Parse LuaDoc of [file:///d%3A/LegendGameJZ/game/runtime/gameclient/src/app/data/itemdef.lua] takes [0.359] sec, size [2505.223] kb.
[10:05:20.840][warn] [#0:script\files.lua:532]: Compile [file:///d%3A/LegendGameJZ/game/runtime/gameclient/src/app/data/NDS.lua] takes [0.153] sec, size [1036.079] kb.
[10:05:21.011][warn] [#0:script\proto\proto.lua:171]: Method [textDocument/documentSymbol] takes [4.409]sec. {
  _closeMessage = "Request cancelled.",
  _closeReason = -32800,
  id = 1,
  jsonrpc = "2.0",
  method = "textDocument/documentSymbol",
  params = {
    textDocument = {
      uri = "file:///d%3A/LegendGameJZ/game/data/long/script/posnpc.lua"
    }
  }
}
[10:05:21.011][warn] [#0:script\proto\proto.lua:171]: Method [textDocument/documentSymbol] takes [4.407]sec. {
  _closeMessage = "Request cancelled.",
  _closeReason = -32800,
  id = 2,
  jsonrpc = "2.0",
  method = "textDocument/documentSymbol",
  params = {
    textDocument = {
      uri = "file:///d%3A/LegendGameJZ/game/data/long/script/posmap.lua"
    }
  }
}
[10:05:21.713][warn] [#0:script\files.lua:532]: Compile [file:///d%3A/LegendGameJZ/game/runtime/gameclient/src/app/NetClient.lua] takes [0.340] sec, size [232.325] kb.
[10:05:24.131][warn] [#0:script\files.lua:532]: Compile [file:///d%3A/LegendGameJZ/game/runtime/gameclient/src/app/ui/UILeftCenter.lua] takes [0.437] sec, size [83.978] kb.
[10:05:25.192][info] [#0:script\workspace\loading.lua:165]: Loaded files takes [8.351] sec: <fallback>
[10:05:25.192][info] [#0:script\workspace\loading.lua:174]: Compile files takes [0.000] sec: <fallback>
[10:05:25.192][info] [#0:script\workspace\loading.lua:175]: Loaded finish:	<fallback>
[10:05:25.192][info] [#0:script\workspace\workspace.lua:350]: Preload finish at:	<fallback>
[10:05:25.239][info] [#0:script\workspace\loading.lua:165]: Loaded files takes [8.396] sec: file:///d%3A/LegendGameJZ/game/data/long
[10:05:25.239][info] [#0:script\workspace\loading.lua:174]: Compile files takes [0.000] sec: file:///d%3A/LegendGameJZ/game/data/long
[10:05:25.239][info] [#0:script\workspace\loading.lua:175]: Loaded finish:	file:///d%3A/LegendGameJZ/game/data/long
[10:05:25.239][info] [#0:script\workspace\workspace.lua:350]: Preload finish at:	file:///d%3A/LegendGameJZ/game/data/long
[10:05:25.567][warn] [#0:script\proto\proto.lua:171]: Method [textDocument/semanticTokens/range] takes [8.513]sec. {
  _closeMessage = "Request cancelled.",
  _closeReason = -32800,
  id = 9,
  jsonrpc = "2.0",
  method = "textDocument/semanticTokens/range",
  params = {
    range = {
      end = {
        character = 0,
        line = 119
      },
      start = {
        character = 0,
        line = 3
      }
    },
    textDocument = {
      uri = "file:///d%3A/LegendGameJZ/game/data/long/script/posnpc.lua"
    }
  }
}
[10:05:25.567][warn] [#0:script\proto\proto.lua:171]: Method [textDocument/foldingRange] takes [4.551]sec. {
  _closeMessage = "Request cancelled.",
  _closeReason = -32800,
  id = 15,
  jsonrpc = "2.0",
  method = "textDocument/foldingRange",
  params = {
    textDocument = {
      uri = "file:///d%3A/LegendGameJZ/game/data/long/script/posnpc.lua"
    }
  }
}
[10:05:25.582][warn] [#0:script\proto\proto.lua:171]: Method [textDocument/documentSymbol] takes [4.556]sec. {
  _closeMessage = "Content modified.",
  _closeReason = -32801,
  id = 11,
  jsonrpc = "2.0",
  method = "textDocument/documentSymbol",
  params = {
    textDocument = {
      uri = "file:///d%3A/LegendGameJZ/game/data/long/script/posnpc.lua"
    }
  }
}
[10:05:25.582][warn] [#0:script\proto\proto.lua:171]: Method [textDocument/documentSymbol] takes [4.555]sec. {
  _closeMessage = "Content modified.",
  _closeReason = -32801,
  id = 12,
  jsonrpc = "2.0",
  method = "textDocument/documentSymbol",
  params = {
    textDocument = {
      uri = "file:///d%3A/LegendGameJZ/game/data/long/script/posmap.lua"
    }
  }
}
[10:05:25.582][warn] [#0:script\proto\proto.lua:171]: Method [textDocument/documentSymbol] takes [4.553]sec. {
  _closeMessage = "Content modified.",
  _closeReason = -32801,
  id = 19,
  jsonrpc = "2.0",
  method = "textDocument/documentSymbol",
  params = {
    textDocument = {
      uri = "file:///d%3A/LegendGameJZ/game/data/long/script/posnpc.lua"
    }
  }
}
[10:05:25.582][warn] [#0:script\proto\proto.lua:171]: Method [textDocument/documentSymbol] takes [4.554]sec. {
  _closeMessage = "Content modified.",
  _closeReason = -32801,
  id = 20,
  jsonrpc = "2.0",
  method = "textDocument/documentSymbol",
  params = {
    textDocument = {
      uri = "file:///d%3A/LegendGameJZ/game/data/long/script/posmap.lua"
    }
  }
}
[10:05:25.582][warn] [#0:script\proto\proto.lua:171]: Method [textDocument/documentColor] takes [8.965]sec. {
  id = 3,
  jsonrpc = "2.0",
  method = "textDocument/documentColor",
  params = {
    textDocument = {
      uri = "file:///d%3A/LegendGameJZ/game/data/long/script/posnpc.lua"
    }
  }
}
[10:05:25.582][warn] [#0:script\proto\proto.lua:171]: Method [textDocument/documentColor] takes [8.965]sec. {
  id = 4,
  jsonrpc = "2.0",
  method = "textDocument/documentColor",
  params = {
    textDocument = {
      uri = "file:///d%3A/LegendGameJZ/game/data/long/script/posmap.lua"
    }
  }
}
[10:05:25.582][warn] [#0:script\proto\proto.lua:171]: Method [textDocument/semanticTokens/range] takes [8.523]sec. {
  id = 10,
  jsonrpc = "2.0",
  method = "textDocument/semanticTokens/range",
  params = {
    range = {
      end = {
        character = 3,
        line = 111
      },
      start = {
        character = 0,
        line = 64
      }
    },
    textDocument = {
      uri = "file:///d%3A/LegendGameJZ/game/data/long/script/posmap.lua"
    }
  }
}
[10:05:25.598][warn] [#0:script\proto\proto.lua:171]: Method [textDocument/inlayHint] takes [8.973]sec. {
  id = 8,
  jsonrpc = "2.0",
  method = "textDocument/inlayHint",
  params = {
    range = {
      end = {
        character = 3,
        line = 111
      },
      start = {
        character = 0,
        line = 34
      }
    },
    textDocument = {
      uri = "file:///d%3A/LegendGameJZ/game/data/long/script/posmap.lua"
    }
  }
}
[10:05:25.598][warn] [#0:script\proto\proto.lua:171]: Method [textDocument/inlayHint] takes [8.976]sec. {
  id = 7,
  jsonrpc = "2.0",
  method = "textDocument/inlayHint",
  params = {
    range = {
      end = {
        character = 0,
        line = 119
      },
      start = {
        character = 0,
        line = 0
      }
    },
    textDocument = {
      uri = "file:///d%3A/LegendGameJZ/game/data/long/script/posnpc.lua"
    }
  }
}
[10:05:25.598][warn] [#0:script\proto\proto.lua:171]: Method [textDocument/foldingRange] takes [4.576]sec. {
  id = 16,
  jsonrpc = "2.0",
  method = "textDocument/foldingRange",
  params = {
    textDocument = {
      uri = "file:///d%3A/LegendGameJZ/game/data/long/script/posmap.lua"
    }
  }
}
[10:05:25.598][info] [#0:script\workspace\loading.lua:165]: Loaded files takes [8.762] sec: file:///d%3A/LegendGameJZ/game/runtime/gameclient/src
[10:05:25.598][info] [#0:script\workspace\loading.lua:174]: Compile files takes [0.000] sec: file:///d%3A/LegendGameJZ/game/runtime/gameclient/src
[10:05:25.598][info] [#0:script\workspace\loading.lua:175]: Loaded finish:	file:///d%3A/LegendGameJZ/game/runtime/gameclient/src
[10:05:25.598][info] [#0:script\workspace\workspace.lua:350]: Preload finish at:	file:///d%3A/LegendGameJZ/game/runtime/gameclient/src
[10:10:59.955][warn] [#0:script\provider\provider.lua:591]: Completion takes 0.150 sec.
[10:15:15.921][info] [#0:script\service\service.lua:141]:
========= Medical Examination Report =========
    --------------- Memory ---------------
        Total: 940.150 MB
        # 00 : 935.969 MB
        # 01 : 1.253 MB
        # 02 : 0.043 MB
        # 03 : 2.841 MB
        # 04 : 0.043 MB
    --------------- Coroutine ---------------
        Total:     734
        Running:   0
        Suspended: 0
        Normal:    0
        Dead:      734
    --------------- Cache ---------------
        Total: 1
        Dead:  0
    ---------------  RPC  ---------------
        Holdon:   0
        Waiting:  0
==============================================

应该是这个改动导致的 66db6ce02196c381131dc71d2482b24bcef8445e

authors: CppCXY HuangZhuo


text:
进一步简化session的过期问题

只需要调用session:save(false)即可

楼主改进了，我就把这个关了

repo: sumory/lor


text:
Change the remote github repo

깃 리모트 변경 하기
기존 리포지토리 깔끔하게 pull / push
git pull
git add .
git commit -m "clean push"
git push

기존 리포지토리 remote 제거
git remote remove origin

새 리포지토리 remote 추가
git remote add origin https://github.com/계정/리포지토리

끝

from https://gist.github.com/480/4681b67d2a906db8c6c1321cc678f05f


text:
程序集签名

由于公司开发环境情况，项目都是有为程序集签名的。请问能在下个版本带上签名吗？
不然我为了一个签名文件 ，要把你新的版本所有代码复制一份。自己生成一个有签名的SqlSugar.dll

OK

这个必须随便加个签名啊 我也觉得特别麻烦 没签名我自己给加了个签名上去

authors: AtlantisDe Dason1986 sunkaixuan

repo: sunkaixuan/SqlSugar


text:
这个是Bug吗？使用 ConditionalModel 查询的时候这种情况会抛异常

使用conditionalModel的时候，当参数FieldName是  别名.字段名 的形式时,如d.item_name，最后生成的sql的参数名会带上. 符号，导致sql执行出错。 如 @Conditionald.item_name0

已修复，下周一更新到GITHUB

authors: herubber sunkaixuan


text:
Updateable(updateobj).As(tablename) 没有生效

版本4.6
当SugarTable的名称和实体类的名臣不一致的时候，使用Updateable(XX).As(XX)是替换表名没有生效

我们这边当使用SugarTable在实体上面标注后，不用写As也能更新
[SugarTable("Address")]     public class AddressEntity : ModelContext

我这儿是需要替换表名的，例如[SugarTable("Address")] public class AddressEntity
Updateable(AddressEntity).As(“AddressTable2”) 这时候是更新不了的

authors: idantony shinyrabbit


text:
feat: Refactor Azure support

This PR overhaul the Azure support.

Adding Account field to ClusterInfo
Switch away from deprecated Azure SDKs
Implement SDK Auth type (this allows to authenticate with local azure cli.)
Choice between Admin KubeConfig (client cert) and User KubeConfig (SSO Login).
Remove Subscription Selector. List and Add command works across multiple subscriptions.
Use real ResourceID as ID inside kubecm

Thank you for your contribution. Since there are currently no unit test cases for Azure, I can't guarantee that this PR will work correctly. So I won't merge this PR for now, can you provide some screenshots of it when it runs correctly?

Otherwise, need to wait until I have time to do some manual testing to make sure he's running correctly.

I can do it at the new year, mid january

@sunny0826 I did a rebase, here are some pics.

Select Cloud

Select Credentials

List clusters

Add clusters

Select config type

Confirm

Summary

Only the ID are problematic, because there are really, really only compared to AWS, making the cloud list table near to unreadable. In the secreenshot, I use a very small font size.
If possible, I would like to hide the ID colum and use it as internal value exclusivly for Azure.

@all-contributors please add @jkroepke  for code

Great, thanks! Looking forward for the next release!


text:
Invitation for co-authors of a JOSS paper

Provide a general description of the issue or problem.
Dear sunraster contributors,
@BaptistePellorceAstro @nabobalis @kakirastern @abit2 @Cadair @ehsteve @tiagopereira @shelbej @EdBehn @asainz-solarphysics @ebuchlin
I am intending to submit a paper on sunraster to the Jounrnal of Open Source Software (JOSS).  As contributors to the sunraster code base I would like to invite you to be co-authors.  If you agree, please reply to this issue with your:

Name you publish under
Affiliation(s)
Affiliation country(ies)
ORCID (optional)

Thanks for your contributions!

Sure:
Nabil Freij
Lockheed Martin Solar and Astrophysics Laboratory, Palo Alto, CA, USA
Bay Area Environmental Research Institute, Moffett Field, CA, USA
0000-0002-6253-082X

Dear Daniel,
I don't think my contribution to sunraster to be significant enough to
deserve to be considered as co-author in the paper.
I do appreciate your email, though.
Congratulations for the job you all have done on sunraster, and especially
to Daniel for coordinating and managing all the efforts!!!
Best regards,
Alberto
On Sun, Feb 19, 2023 at 6:29 AM DanRyanIrish @.***>
wrote:

Provide a general description of the issue or problem.
Dear sunraster contributors,
@BaptistePellorceAstro https://github.com/BaptistePellorceAstro
@nabobalis https://github.com/nabobalis @kakirastern
https://github.com/kakirastern @abit2 https://github.com/abit2 @Cadair
https://github.com/Cadair @ehsteve https://github.com/ehsteve
@tiagopereira https://github.com/tiagopereira @shelbej
https://github.com/shelbej @EdBehn https://github.com/EdBehn
@asainz-solarphysics https://github.com/asainz-solarphysics @ebuchlin
https://github.com/ebuchlin
I am intending to submit a paper on sunraster to the Jounrnal of Open
Source Software (JOSS). As contributors to the sunraster code base I would
like to invite you to be co-authors. If you agree, please reply to this
issue with your:

Name you publish under
Affiliation(s)
Affiliation country(ies)
ORCID (optional)

Thanks for your contributions!
—
Reply to this email directly, view it on GitHub
https://github.com/sunpy/sunraster/issues/229, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIVAR5QEJK7SVYAHFQIWQILWYIU25ANCNFSM6AAAAAAVA7YF7A
.
You are receiving this because you were mentioned.Message ID:
@.***>

Sign me up, you have the deets already :p

I have just submitted the sunraster paper to JOSS.  Thanks to all those who agreed to be co-authors.

authors: Cadair DanRyanIrish asainz-solarphysics nabobalis

repo: sunpy/sunraster


text:
Question about paper

As the fig.2 show that you get the CxC matrix by the fc layer, why did you say the CNNs so many times? And the CNNs in Fig2 is just to compress as you said in session 5.1.

I'm sorry but I don't get the question, could you please explain in more details?

I means the CNNs  you mentioned in the paper's section 3.2 is for transform T, but actually is done by Fc layer, right? The CNNs is just for reducing dimensions.

authors: diaodeyi sunshineatnoon

repo: sunshineatnoon/LinearStyleTransfer


text:
Release 1.202.4 and later break seed on reset - Windows

Describe the bug
Since Release 1.202.4, db reset no longer recognises my seed.sql file even though it exists in the expected location, supabase/seed.sql
To Reproduce
Steps to reproduce the behavior:

Update to supabase cli v1.202.4 or later
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots

System information

Version of OS: Windows 11
Version of CLI: v1.202.4 or later
Version of Docker: Docker Desktop v4.34.2
Versions of services:

        SERVICE IMAGE      │      LOCAL       │   LINKED
 ─────────────────────────┼──────────────────┼─────────────
   supabase/postgres      │ 15.6.1.127       │ 15.6.1.127
   supabase/gotrue        │ v2.162.1         │ v2.162.1
   postgrest/postgrest    │ v12.2.3          │ v12.2.3
   supabase/realtime      │ v2.30.34         │ -
   supabase/storage-api   │ v1.11.7          │ v1.11.7
   supabase/edge-runtime  │ v1.58.11         │ -
   supabase/studio        │ 20240923-2e3e90c │ -
   supabase/postgres-meta │ v0.83.2          │ -
   supabase/logflare      │ 1.4.0            │ -
   supabase/supavisor     │ 1.1.56           │ -

This is due to a bug in path separator handling. Could you try the beta release?
npx supabase@beta db reset

@sweatybridge That's fixed it. Thanks.
$ npx supabase@beta db reset
Need to install the following packages:
supabase@1.204.3
Ok to proceed? (y) y

Resetting local database...
Recreating database...
Setting up initial schema...
Seeding globals from roles.sql...
Applying migration ....
Seeding data from supabase/seed.sql...
Restarting containers...

Still seeing this issue on db pull and push:
npx supabase db pull --local
No seed files matched pattern: supabase/seed.sql
No seed files matched pattern: supabase/seed.sql

Not sure why as I don't believe the seed is used in these commands.

@sweatybridge See the original bug at the top here. db reset was fixed i.e. the No seed file matched pattern warning no longer shows with the db reset command. It was an issue with reading the file system correctly on windows I believe. However, I'm still seeing the warning when using db push and db pull

authors: DuncanLHS sweatybridge

repo: supabase/cli


text:
supabase start fails with error 'Container ... is restarting, wait until the container is running'

Bug report
Describe the bug
supabase start fails and produces error 'Error: Error response from daemon: Container 39ecdf... is restarting, wait until the container is running'
To Reproduce

Run supabase init
Run supabase start

Expected behavior
Supabase starts.
System information

OS: macOS
Docker: 20.10.16
Supabase Cli: 0.26.2
supabase/deno-relay: v1.2.0
supabase/gotrue: v2.6.18
supabase/phadmin-schema-diff: cli-0.0.4
supabase/postgres: 14.1.0.21
supabase/postgres-meta: v0.33.2
supabase/realtime v0.22.4
supabase/storage-api: v0.15.0
supabase/studio: latest

Additional context
There is a container created from image 'supabase/postgres' but as quick as it appears it is deleted and I can't access the logs.
Also i noticed that supabase init only creates a single file 'supabase/config.toml'. The docs https://supabase.com/docs/guides/local-development mention that a 'supabase/seed.sql' is created by supabase init. Should supabase init be creating more files?

I was able to fix this by deleting all containers and volumes then restarting supabase.

@egor-romanov could we reopen this? I am suddenly experiencing this in a GitHub Action. Nothing changes, just from one action run to the other it started to always throw this error...

I'm seeing the same thing

I have opened an urgent ticket with the supabase support since this is blocking us from running any ci.

Hello, are you able to pin the CLI version on GHA to a previously working one for the time being? Possibly 1.4.7
You can refer to a working example here https://github.com/supabase/setup-cli
We will look into the issue soon to fix it in the next release.

Hello, are you able to pin the CLI version on GHA to a previously working one for the time being? Possibly 1.4.7

Using a previously working version doesn't seem to work.
When this started failing I was on 1.4.2. I upgraded to 1.5.0 and have the same error.

Same here! Same problem occurs after downgrading. Also, it worked before on 1.5.0, I did not upgrade or change anything. It suddenly stopped working.

Thank you for reporting this. I was trying to reproduce it, but no luck.
Can you confirm that this problem only occurs on CI runners?

Can you confirm that this problem only occurs on CI runners?

Only on GitHub Actions for me. Works fine locally.

Can you confirm that this problem only occurs on CI runners?

Same here. I removed my docker image cache locally, but it downloads the images and launches the containers as expected.
GH runner versions are also exactly the same...
Current runner version: '2.296.2'
Operating System
  Ubuntu
  20.04.5
  LTS
Runner Image
  Image: ubuntu-20.04
  Version: 20220922.2
  Image Release: https://github.com/actions/runner-images/releases/tag/ubuntu20%2F20220922.2
Runner Image Provisioner
  1.0.0.0-main-20220916-1

I've created https://github.com/supabase/setup-cli/pull/59 which I hope will reproduce the problem. Can someone from supabase please approve running the workflows on this PR?

We found the root cause: the supabase/postgres image that the CLI depends on was updated 10h ago with an arm64 build. Unfortunately the multi-arch manifest was not updated correctly, resulting in arm64 images being pulled on x86 machines. This broke GHA and anyone trying to supabase start on a fresh x86 computer without any locally cached docker images.
We are still looking into fixing the issue and will post an update once that's resolved.

It sounds like supabase-cli doesn't pin the versions of the docker images it fires up. If an update to supabase/postgres can break existing installations this way, does this mean the :latest docker image is downloaded rather than a specific version?
How can we have reproducible builds if this is the case?
Have you considered pinning the docker image versions?

I see on supabase/postgres that 14.1.0.71 was pushed, but latest is still pointing to an older version (14.1.0.61).
Maybe an opportunity to review your release process?

Hey folks-sorry about that; this was an unintended side-effect of my work on getting arm64 images out. I made the mistaken assumption that the repo was immutable (something we do by default), but it looks like public ECR repos don't support immutability. To close out this thread:

I'm re-uploading the x86 image, and it should fix fresh pulls once that completes (in an hour or so)
we'll fix the multi-arch build to avoid running into this again
@sweatybridge is working on a new CLI build that uses a newer release of postgres, which should avoid any issues with the arm image being picked up off a cache and causing issues

@aslakhellesoy towards your specific concerns:

we haven't been using latest (or any other similar mutable tags) in quite a while; it's been left there to avoid breaking anyone that was using it (and bumping it up would break them). No good options here, imo this was the less harmful one.
the supabase-cli does pin the images involved ( c.f. internal/utils/misc.go )

We have released CLI v1.5.1 which uses postgres 14.1.0.71 and I have verified supabase start is working on GHA.
We will update 14.1.0.66 image later to fix older CLI versions.

Thanks a lot for the quick turnaround to fix this. I'm no longer getting the previous error, but I am now getting another one. Here is my GitHub Action config:
- name: Install Supabase
  uses: supabase/setup-cli@v1.0.2
  with:
    version: 1.5.2

- name: Start Supabase
  run: supabase start
  env:
    # https://github.com/supabase/cli/issues/419#issuecomment-1232025865
    SUPABASE_INTERNAL_IMAGE_REGISTRY: docker.io

I'm getting this error:
Pulling images...
Pulling from supabase/postgres...
Pulling from supabase/postgres...
Pulling from supabase/postgres...
Pulling from supabase/postgres...
Pulling from supabase/postgres...
Pulling from supabase/postgres...
Pulling from supabase/postgres...
Pulling from supabase/postgres...
Pulling from supabase/postgres...
Pulling from supabase/postgres...
Pulling from supabase/postgres...
Starting database...
Restoring branches...
Setting up initial schema...
Applying migration 20220429171120_create_profiles.sql...
Applying migration 20220429223619_rls-and-trigger.sql...
Applying supabase/seed.sql...
Starting containers...
Failed to restart storage-api: Error response from daemon: No such container: supabase_storage_server
Error: Error response from daemon: No such image: kong:2.8.1

If I remove the SUPABASE_INTERNAL_IMAGE_REGISTRY environment variable I get a similar error:
Error: Error response from daemon: No such image: public.ecr.aws/t3w2s2c9/kong:2.8.1

Any idea why kong:2.8.1 is not found? I can see it here: https://hub.docker.com/_/kong

It looks to me like supabase 1.5.2 isn't pulling all the images it needs. My workaround for now is to explicitly pull all the images before supabase start:
- name: Start Supabase
  run: |
    docker pull public.ecr.aws/t3w2s2c9/postgres:14.1.0.71 &&
    docker pull public.ecr.aws/t3w2s2c9/postgres:14.1.0.66 &&
    docker pull public.ecr.aws/t3w2s2c9/storage-api:v0.20.1 &&
    docker pull public.ecr.aws/t3w2s2c9/postgres-meta:v0.45.0 &&
    docker pull public.ecr.aws/t3w2s2c9/gotrue:v2.15.3 &&
    docker pull public.ecr.aws/t3w2s2c9/studio:v0.1.0 &&
    docker pull public.ecr.aws/t3w2s2c9/pgadmin-schema-diff:cli-0.0.5 &&
    docker pull public.ecr.aws/t3w2s2c9/kong:2.8.1 &&
    docker pull public.ecr.aws/t3w2s2c9/inbucket:3.0.3 &&
    docker pull public.ecr.aws/t3w2s2c9/postgrest:v9.0.1.20220717 &&
    docker pull public.ecr.aws/t3w2s2c9/realtime:v0.22.7 &&
    supabase start

Sorry I accidentally renamed a bunch of images in #488. Should be fixed in 1.5.3

It's still broken. My GitHub Action:
- name: Install Supabase
  uses: supabase/setup-cli@v1.0.2
  with:
    version: 1.5.3

- name: Start Supabase
  run: supabase start

The error:
Applying supabase/seed.sql...
Starting containers...
Error: Error response from daemon: No such image: public.ecr.aws/t3w2s2c9/postgres-meta:v0.45.0
Error: Process completed with exit code 1.

Might I suggest that rather than relying on users to test that supabase start works on GitHub Actions, you have your own CI somewhere that verifies this and alerts you when it breaks? And maybe automate the parts of your release process that is prone to human error?
I've managed to make it start with a new workaround (my previous workaround spuriously fails with toomanyrequests: Rate exceeded - as mentioned in https://github.com/supabase/cli/issues/419#issuecomment-1232025865)
- name: Start Supabase
  run: |
    docker pull postgres:14.1.0.71 &&
    docker pull postgres:14.1.0.66 &&
    docker pull storage-api:v0.20.1 &&
    docker pull postgres-meta:v0.45.0 &&
    docker pull gotrue:v2.15.3 &&
    docker pull studio:v0.1.0 &&
    docker pull pgadmin-schema-diff:cli-0.0.5 &&
    docker pull kong:2.8.1 &&
    docker pull inbucket:3.0.3 &&
    docker pull postgrest:v9.0.1.20220717 &&
    docker pull realtime:v0.22.7 &&
    supabase start
  env:
    # https://github.com/supabase/cli/issues/419#issuecomment-1232025865
    SUPABASE_INTERNAL_IMAGE_REGISTRY: docker.io

Error: Error response from daemon: No such image: public.ecr.aws/t3w2s2c9/postgres-meta:v0.45.0

This appears to be a new ephemeral error rather than a regression. Out of 131 supabase start commands we ran from CI on 1 Oct, 41 failed with a missing image error. After releasing v1.5.4, we ran 97 tests on 2 Oct and all of them succeeded. This also fixes rate limit error when pulling from ECR.

Might I suggest that rather than relying on users to test that supabase start works on GitHub Actions, you have your own CI somewhere that verifies this and alerts you when it breaks?

Thanks for the feedback. We have since added a few automated tests to prevent regression.

CI workflow in cli repo now tests supabase start on each PR and merge to main
CLI Start workflow in setup-cli repo runs supabase start twice a day on version 1.5.4 and 1.0.0

And maybe automate the parts of your release process that is prone to human error?

We have also refactored the image pulling code to make it less prone human error. We now define an array of docker images and call the same function to pull each one.

installed supabase cli with all dependecies like docker and all but when i run
supabase start (command)
docker container is created and  inbetween something going wrong and stop container and not working and give me error

::internal_events::api: API server running. address=0.0.0.0:9001 playground=http://0.0.0.0:9001/playground
2024-10-23T09:12:02.412007Z  INFO vector::app: All sources have finished.
2024-10-23T09:12:02.412010Z  INFO vector: Vector has stopped.
2024-10-23T09:12:02.413354Z  INFO vector::topology::running: Shutting down... Waiting on running components. remaining_components="logflare_auth, logflare_kong, logflare_db, logflare_realtime, logflare_functions, logflare_rest, logflare_storage" time_remaining="59 seconds left"
Stopping containers...
supabase_vector_test_spabase container is not ready: unhealthy
Try rerunning the command with --debug to troubleshoot the error.

give me error container is unhealthy. I followed all steps but it's working in refernce video but not wrok for me.
if some one getting same issue please help me for resolve this.

authors: aslakhellesoy brahmveda-shreya darora egor-romanov kaheahendrickson psteinroe sweatybridge


text:
New Studio Version

Updates service studio new version to 20240205-b145c86.

Pull Request Test Coverage Report for Build 7787308586

0 of 0   changed or added relevant lines in 0 files are covered.
5 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.03%) to 58.573%

Files with Coverage Reduction
New Missed Lines
%

internal/gen/keys/keys.go
5
11.76%

Totals

Change from base Build 7779731705:
-0.03%

Covered Lines:
6159

Relevant Lines:
10515

💛  - Coveralls

authors: coveralls ivasilov


text:
Bug with supabase.auth.getSessionFromUrl();

Bug report
Describe the bug
When i authenticate with google the user gets authenticated and i get their credentials through supabase.auth.user(), but i can't get the user object with the supabase.auth.getSessionfromUrl function.
This bug only exists if you don't add the { storeSession: true } option in the supabase.auth.getSessionFromUrl function.
To Reproduce
This is the function thats called signIn
export const signIn = () =>
  supabase.auth.signIn(
    { provider: 'google' },
    { redirectTo: 'http://localhost:3000/auth/callback' }
  );

I just use this function at a button press like this

import {signIn} from "@core/auth";

export default function PageComponent() {

  ....

  return (
    <>
      <button onClick={signIn}>
        Sign in
      </button>
      ...
    </>
  )
}

When its redirected to the /auth/callback route. I call this function
 await supabase.auth.getSessionFromUrl();

And then this response
{
    "data": null,
    "error": {
      "message": "TypeError: Cannot read properties of undefined (reading 'api')",
      "stack": "TypeError: Cannot read properties of undefined (reading 'api')
        at GoTrueClient.js:320:39
        at Generator.next (<anonymous>)
        at GoTrueClient.js:7:1
        at new Promise (<anonymous>)
        at __awaiter (GoTrueClient.js:3:1)
        at getSessionFromUrl (GoTrueClient.js:298:1)
        at _callee$ (callback.tsx:10:40)
        at tryCatch (runtime.js:63:16)
        at Generator.invoke [as _invoke] (runtime.js:293:1)
        at Generator.next (runtime.js:118:1)"}
}

Expected behavior
What i want it to do is to redirect to the google auth page sign in, and then give me the credentials in the method:
supabase.auth.getSessionFromUrl(); // <-- this

This method is in the /auth/callback route, but for some reason i get this error
{
    "data": null,
    "error": {
      "message": "TypeError: Cannot read properties of undefined (reading 'api')",
      "stack": "TypeError: Cannot read properties of undefined (reading 'api')
        at GoTrueClient.js:320:39
        at Generator.next (<anonymous>)
        at GoTrueClient.js:7:1
        at new Promise (<anonymous>)
        at __awaiter (GoTrueClient.js:3:1)
        at getSessionFromUrl (GoTrueClient.js:298:1)
        at _callee$ (callback.tsx:10:40)
        at tryCatch (runtime.js:63:16)
        at Generator.invoke [as _invoke] (runtime.js:293:1)
        at Generator.next (runtime.js:118:1)"}
}

Screenshots
If applicable, add screenshots to help explain your problem.
System information

OS: Windows 11
Browser Brave browser
Version of supabase-js: 1.29.4
Version of Node.js: 16.13.1

Closing for lack of activity and I think this has already been taken care of with the release of v2.

authors: hf vincent-thomas

repo: supabase/gotrue-js


text:
RFC: sending JWT in header

Feature request
Is your feature request related to a problem? Please describe.
Currently when redirecting from GoTrue to site url we send the token as fragment which isn't accessible on the server, meaning we have no ability to read the token in a server-side auth route for example, which is why we currently need the AJAX request to set our auth cookie: https://github.com/supabase/supabase/blob/master/examples/nextjs-with-supabase-auth/pages/index.js#L19-L31  which isn't an ideal experience.
Describe the solution you'd like
We should make the JWT accessible server-side so that users can set their site URL to a server-route (e.g. with nextjs /api/auth) where they set their application auth cookie before the page is rendered to avoid unwanted side effects.
I think the easiest way would be for us to always set the cookie header, which is currently only set conditionally, e.g. https://github.com/supabase/gotrue/blob/master/api/verify.go#L127-L131 but I'm not sure if there is any downside to always sending the Cookie header. If not, we could just remove the condition and always set it.
Additional context
For example, Auth0 sets the JWT in a request header when they redirect to your return URL:
// console.log(req)
{
// ...
  url: '/api/callback?code=KKo1d_njmlNx9Czw6fK_iiIMpPigpSyWUphj2RnQHlh1Z&state=eyJyZXR1cm5UbyI6Imh0dHA6Ly9sb2NhbGhvc3Q6MzAwMCJ9',
  method: 'GET',
  query: {
    code: 'KKo1d_njmlNx9Czw6fK_iiIMpPigpSyWUphj2RnQHlh1Z',
    state: 'eyJyZXR1cm5UbyI6Imh0dHA6Ly9sb2NhbGhvc3Q6MzAwMCJ9'
  },
  [Symbol(kHeaders)]: {
    host: 'localhost:3000',
    connection: 'keep-alive',
    'cache-control': 'max-age=0',
    'upgrade-insecure-requests': '1',
    'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.69 Safari/537.36',
    accept: 'text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9',
    'sec-fetch-site': 'cross-site',
    'sec-fetch-mode': 'navigate',
    'sec-fetch-user': '?1',
    'sec-fetch-dest': 'document',
    'sec-ch-ua': '"Google Chrome";v="95", "Chromium";v="95", ";Not A Brand";v="99"',
    'sec-ch-ua-mobile': '?0',
    'sec-ch-ua-platform': '"macOS"',
    'accept-encoding': 'gzip, deflate, br',
    'accept-language': 'en-GB,en;q=0.9,de-DE;q=0.8,de;q=0.7,sv-SE;q=0.6,sv;q=0.5',
    cookie: 'nonce=CMsL6Gf_6--6BWvmVoa6dN5JjEQfk-3akVAsJOFSLww.ci2MKZ6bOPG0mVKUdIn4AYuc5V6cGTt5ZJCm1Wpqp-c; state=eyJyZXR1cm5UbyI6Imh0dHA6Ly9sb2NhbGhvc3Q6MzAwMCJ9.8z0o6e3gtALtDo9xVT-Rj6kxubkVXSV_jCNlggLV0CQ; code_verifier=TlQbgMQi55G3RFFm_OgD0Iv6KMoz9gcRCqu_fmXxVcA.eCfeYKoksLKLiPgqv7Iovfvzr9x3eE9Fb1yPHNvCeZs'
  },
// ...
}

The cookie header is then read server-side in the callback route (https://github.com/auth0/nextjs-auth0/blob/main/src/auth0-session/handlers/callback.ts#L38-L56) to set up the OpenID issuer which makes requests to Auth0. I don't think we need to whole OpenID issuer (just yet) but I think we should make the JWT accessible server-side to facilitate the expected DX.

Correction, Auth0 does not set the JWT in the header but rather the params needed to create the OpneID issuer client I guess?

cool - it looks like there are 2 possibilities
Option 1: Follow Auth0 flow
Follow the Auth0 flow. In this case it looks like we need to send some additional data (state param, nonce etc), which is then used to verify and create a new session.
Option 2: Send the session directly.
Send the session data in a cookie, as you point out here. This is very similar to how we attach the session to the URL fragment, which is inaccessible to the server.
questions:

if the cookie is set on a GoTrue server it should be accessible on a xxxx.supabase.co domain only right? Does this need to be another header/method of attaching the session info?
are there any security concerns around the session data leaking if it's in a header? I guess it's no less secure than the URL fragment, which is already a part of the OAuth spec

I think option 2 is the low-hanging fruit here. We can think about option 1 later down the road.

if the cookie is set on a GoTrue server it should be accessible on a xxxx.supabase.co domain only right? Does this need to be another header/method of attaching the session info?

Correct, the user's server can't access the cookie, but it can access the cookie header of this specific request. And we'd then simply extend our existing supabase.auth.api.setAuthCookie(req, res) functionality to look for the JWT in the header and then set the user's application cookie which is then used for subsequent requests throughout their app 👍

are there any security concerns around the session data leaking if it's in a header? I guess it's no less secure than the URL fragment, which is already a part of the OAuth spec

Yah, that's exactly what I'm looking to confirm. I think it's fine as long as everything is happening via HTTPS? But also not an expert here unfortunately.

Oh, and lastly we would also need to enable the gotrue server to accept form submit requests for email sign-in and for sign-out requests. These requests will then also need to be redirected back to the site url. That way we can ensure that all sign-up/sign-in/sign-out requests go through the user's /auth server route to update the application state.

I think the form submissions are an immediate go-ahead. There are no security concerns there - in fact I think that's how netlify's version works

And we'd then simply extend our existing supabase.auth.api.setAuthCookie(req, res) functionality to look for the JWT in the header and then set the user's application cookie which is then used for subsequent requests throughout their app

We will need to make this cookie http-only in gotrue-js. Currently it is not, which makes it less secure than just using local storage.

are there any security concerns around the session data leaking if it's in a header?

Usually the token is sent in the hash, so that the server doesn't get access to it. But since the whole point here is to get the server access to the jwt, I think its fine sending it in the header.

We will need to make this cookie http-only in gotrue-js. Currently it is not, which makes it less secure than just using local storage.

This is part of the setAuthCookie of the auth.admin namespace which only works server-side and sets an http-only cookie via the user's server-side environment: https://github.com/supabase/gotrue-js/blob/master/src/lib/cookies.ts#L134

Ah didnt dig into the serializeCookie function - this is perfect then!

We should also figure out https://github.com/supabase/supabase/discussions/889 as part of this.

If I'm understanding the intended implementation of option 2 correctly, a notable downside is that there would be no way for this to work if Javascript were disabled on the client side. I'm not yet fully acquainted with all of how GoTrue works, so there's room for me to be missing something obvious to others, but I think it would be ultimately preferable if client-side javascript were not required to use Supabase. With RLS and authentication, ISTM that Supabase would still have a lot to offer without client-side Javascript, so it seems ultimately suboptimal for it to require it in all scenarios, especially if the goal is to enable the server-side.

If I'm understanding the intended implementation of option 2 correctly, a notable downside is that there would be no way for this to work if Javascript were disabled on the client side.

I'll have to agree here-- I'm trying to make a Javascript-less app with Supabase on the backend (through an API of course), so sending the JWT and whatever other info in a header would make server-side authentication so much easier.

I believe solution 2 would work with no client-side JS. If I understand correctly, the idea is to set the auth cookie in the redirection made by gotrue. If the cookie is set this way, your future requests to your server would contain the authentication cookie. You could then use this token to make your server-side requests to supabase.
Is there any progress on this issue? Did someone already take a stab at it?

Hey everyone I'm on the Supabase Auth team here to shed some light on this issue.
We don't want Supabase Auth to rely on cookies for authentication and authorization. It is common in the industry now to use the concept of access and refresh tokens as the preferred mechanism for authenticating and authorizing a user in an application. Cookies are a relatively browser-centric technology that does not fit well with non-browser applications such as native mobile apps, CLI and desktop apps, apps on TVs and IoT devices.
Therefore GoTrue does not really use cookies (although there is some old code that issues them). Developers should not rely on those cookies for any purpose.
That being said, cookies are a great way to convey the access and refresh tokens in web apps, especially for cases where the application is not a SPA and has a server component that requires some user authorization to take place. This is becoming increasingly popular with server-side rendering frameworks, and is traditional in server-based (Django, Rails, PHP, ...) web apps. Here's a snippet of code you can use to extract the access and refresh tokens from within the SPA and set it as cookies on the origin where your app is hosted:
supabase.auth.onAuthStateChange((event, session) => {
  if (event === "SIGNED_OUT" || event === "USER_DELETED") {
    // delete cookies on sign out
    const expires = new Date(0).toUTCString();
    document.cookie = `my-access-token=; path=/; expires=${expires}; SameSite=Lax; secure`;
    document.cookie = `my-refresh-token=; path=/; expires=${expires}; SameSite=Lax; secure`;
  } else if (event === "SIGNED_IN" || event === "TOKEN_REFRESHED") {
    const maxAge = 100 * 365 * 24 * 60 * 60; // 100 years, never expires
    document.cookie = `my-access-token=${session.access_token}; path=/; max-age=${maxAge}; SameSite=Lax; secure`;
    document.cookie = `my-refresh-token=${session.refresh_token}; path=/; max-age=${maxAge}; SameSite=Lax; secure`;
  }
})

We are aware about the problems with having a redirect-style flow to get back the access and refresh tokens issued for a login session, however this flow does work for the majority of use cases today. Both browser and native mobile apps use the concept of URLs to finish authentication flows.
An alternative to this flow which we are keen on implementing is the Proof-Key Code Exchange method (PKCE) that has multiple security benefits and also supports a larger set of use cases including server-only, desktop and CLI apps. There are no concrete timelines for this as I write this comment, but it is relatively high on our priority list.
Unfortunately, this style of authentication does assume a rich client -- one that is able to execute code instead of present static markup. Thus it does not support browser based apps without JavaScript. GoTrue and Supabase Auth are just not suitable for that type of authentication, and it is probably better to look for an alternative.

While it is your right to write off customers like this if you'd prefer not to have them, I want to make sure that you understand what I think might be a reasonable alternative.

Agreed. I completely stopped using Supabase Auth and made a custom solution (still using Supabase) to do user authentication. I had to do this as I was moving my app to full SSR for better performance (big app, JS payloads were huge).

Rather than write off customers that wish to lean into progressive enhancement, you may be able to reasonably retain them by permitting switching the # to a ? in the redirect url from Supabase auth.

This is a much more optimal solution. I had even opened an issue for this (#472) but it was dismissed for security reasons (for good reason). Due to this, even having a warning about security could be optimal (as most users that would do this, would know what they're doing, and likely just using SSR like I was).
I am really hoping this RFC passes. We've effectively gone full-circle with web-apps, going from "JS hydration is the future" back to "Server-side rendering is the future". Supabase should be able to adapt to whatever the user case may be.

We originally switched to params but realised that it might not be as secure as # because params are sent to the server and can be modified in transit so we switched it back

@jackmerrill this is from the ticket you linked. The point about it being modified in transit seems wrong unless the client is compromised (where the fragment would be no better) or the site is not using HTTPS (where the scripts themselves can be compromised on the way to the browser).
The further concern that I've heard in the past is that servers will often log URLs, so if they contain a long-lived secret that could be an unnecessary exposure. This seems to me to be a server configuration challenge, not a Supabase vulnerability; but its a common enough one that I can find some utility in a single-use token approach instead of sending the JWT directly in the URL.

With the recent release of server-side rendering docs, we have confirmation that the logging concern is their stated concern with merely putting the authentication token in querystring parameters.
What I have done in the past to address this concern is to have a one-time exchange secret that the receiver, whether client or server, could use to obtain the JWT. But once that token is used, any other party attempting to use the same token would fail, addressing the concern of secrets being logged. This mode of operation means that any attempt to re-use a token will either (a) fail or (b) cause loud errors for the legitimate party attempting to use the token.
While I don't expect implementing this suggestion is likely to be very high on the priority list, would the Supabase team be open to considering a pull request implementing this mode of operation? I don't have a good sense of what kind of challenge that would be to implement, but if the Supabase team is willing to encourage that type of contribution, then at least those who care about this can know that there is a potential path to a solution.

I've recently done a fair bit of (re-)digging into how OAuth 2 and OpenID connect work. GoTrue has some trappings that connect it to OAuth2 as a provider in additional to being an OAuth client for many other providers. Particularly, it implements a /token endpoint that is compatible with OAuth 2, for refresh_token and password grants.
Further, looking at the examples from the server-side rendering docs, it appears that the redirection that is implemented also follows patterns that seem strongly inspired by OAuth 2 implicit grant, but where the oauth flow is not triggered by the client. Of particular note is that implicit grant is specified to use URL fragments to communicate. So contrary to my request, I applaud the Supabase for not doing as I preferred. I was wrong.
So where does that leave those of us who would like to see Supabase have a story for sites that might be better served by avoiding client-side Javascript, or at least allowing its absence?
First, I'll note that OAuth 2's Implicit Grant is now officially discouraged by the OAuth 2 working group. This is not to say its insecure, but that the reasons that motivated this approach exist at all (Javascript clients, primarily) are no longer major consideration, and that the authorization_code grant is generally better even for Javascript clients.
With that in mind, ISTM that there would be real value in implementing something analogous to the authorization_code grant, that would return a single-use authorization code that would be used at the /token API endpoint to obtain access and refresh tokens. This is expected to be returned in the URL in the OAuth 2 spec, and therefore could be used by either the server or the client, as appropriate for the individual case, and wouldn't fall prey to the replay attack challenges. An interesting benefit that the OAuth 2 implementers note is that this gives additional confidence that the access and refresh tokens are actually received by the client, where implicit flow does not confirm that.
That all seems like a fairly large job, with some significant changes required in GoTrue. A worthwhile direction, but one that I wouldn't know how anybody might wish to prioritize.

Hey @ryanhiebert,
Thank you for your suggestion and opinion. It really means a lot to us.
PKCE (authorization_code grant) is very high up on our priority list. Today we're finishing up with Launch Week 6 and will start planning our next steps in the coming days. At this time we don't publicly share our roadmaps but we hope to make some progress towards this in the next 2-3 months.

@dutchdata it is possibly to do without any client-side JS by utilising PKCE: https://supabase.com/docs/guides/auth/server-side/email-based-auth-with-pkce-flow-for-ssr

Closing this as Supabase Auth itself is more of an API server, and you can use custom storage adapters or even service workers to achieve this functionality.

authors: florianlouvet hf inian jackmerrill kiwicopple ryanhiebert thorwebdev

repo: supabase/gotrue