Caddy 2 port

@mholt has announced that Caddy 2 may hit stable by early next year.  Based on a quick glance at the new docs, there are lots of changes to how plugins (soon to be called modules) work, and it will likely require a complete rewrite to support JWT auth in Caddy 2.  I plan to post a deprecation notice on the readme so people know that no further development will happen on this plugin unless it's to address a security vulnerability.
I haven't decided whether I'll port this to the new module system as I rarely use JWT anymore.  I think paseto has a better design and less foot guns if you are starting from scratch on a new application.
This issue is meant as a discussion area for a potential port to Caddy v2.  For anyone considering an auth module for Caddy, I'd offer the following ideas based on several years of experience hearing about various use cases.
Eliminate all Caddyfile-style configuration directives that express auth logic
One of the major drawbacks of v1-style plugins was the use of the Caddyfile for expressing auth logic.  While the system of allow user bob worked, it's awkward to use a configuration language to express logic.  This is a recurring problem with projects that use config files to express branching logic that depends on external state (e.g., Ansible, Kubernetes Helm templates, etc.) where if-then-else logic is bolted on to a declarative config file format.  This can be solved by using Starlark as suggested below, but there may be other ways to move this logic outside Caddy configuration and into an environment that is more suitable to scripting.  One option is to delegate auth decisions to a separate microservice as in caddy-extauth, so that authorization can be controlled by the user in any language, but easily integrated as a middleware-type plugin.
The new module should take advantage of the integrated Starlark scripting capability to provide a platform for users to express advanced auth flows.
Starlark has a python-like syntax that would allow someone to express all kinds of auth flows and special cases that are awkwardly handled as edge cases in this plugin.  Things like extracting tokens from oddly named cookies, stripping claim prefixes, and returning non-standard HTTP responses would be relatively easy in Starlark and keep these edge cases out of the module code.

token = token_from_cookie("my-auth-token")
secret = secret_from_env("JWT_SECRET")

if claim(token, "user") == "bob" and valid(token, HS256, secret):
     return ok()
else:
     return redirect(301, "https://mysite.com/login")

The starlark runtime can be injected with custom functions (implemented in Go), such as valid(token, algorithm, secret) and claim(token, field), that would extract claims and validate tokens, return various HTTP responses, set headers, allow fine grained auth rules for different paths, etc. so that nearly any use case can be under the control of the user while keeping the module code free of special cases.
Address drawbacks of delegating auth decisions to user scripts
One downside of the ideas above is that it would be a lot easier for a user to shoot themselves in the foot unless they are familiar with the design errors in JWT.  There are several known vulnerabilities that arise from the JWT specification, like attacks based on monkeying with the alg header field in order to control how JWT validation is applied.
Care should be taken in what functions are supplied to the user so that the design of the API prevents them from insecurely validating tokens.

 I think you raise some really good points.
Ideally, the logic will be abstracted away from users enough that they can't make security logic errors. That's kind of the Caddy way.
One possibility is to sacrifice some flexibility for the most common, simple configs, that can be expressed in a declarative syntax. Then allow Starlark scripting to handle more complex, imperative logic. But maybe the Starlark APIs can be designed in a way that it still provides the flexibility users need, without the possibility of making security mistakes.
Also, it would be preferable if it was implemented as native Go code, especially when the need is common enough. Go code will always be faster than an embedded scripting language, and easier to maintain. (Although Starlark is quite fast.)
Caddy 2 has an HTTP authentication module which, I hope, can help provide authentication for HTTP requests by any kind of provider. Right now, the only provider is "basicauth" which uses HTTP Basic Authentication. But I hope that it will one day support plugins that provide JWT, OAuth2, and other methods.
Auth providers implement this interface:
// Authenticator is a type which can authenticate a request.
// If a request was not authenticated, it returns false. An
// error is only returned if authenticating the request fails
// for a technical reason (not for bad/missing credentials).
type Authenticator interface {
	Authenticate(http.ResponseWriter, *http.Request) (User, bool, error)
}

We're still in beta, though, so we can and should change this interface if this is not sufficient.
My hope for this authentication module is that you can provide 1 set of user accounts or credentials or whatever, and just plug in and configure various ways to authenticate them. I don't know if that's possible for all auth methods, but it sure would be nice, right? (i.e. one list of accounts that you can authenticate via basic auth, Oauth2, JWT, etc.)
Let me know what you think, or if this is helpful at all. Also if there are any changes to be made, now is the time!

Hey Matt, thanks for that info.  I think it's definitely possible to implement that interface across a wide variety of auth methods.  One change I'd like to see is to expand the definition of the User struct to allow passing additional metadata about the user that could then be acted on by subsequent middleware.  This would be great for JWT, Paseto, and other formats that pass arbitrary claim information as part of the token.
For example, a metadata field as a json.RawMessage would help a lot in being able to chain an auth middleware with a subsequent Starlark or other middleware that would act on claim information passed along in the context.
type User struct {
   ID  string
   Metadata json.RawMessage
}

First of all, thanks so much for the work you did on this plugin. It has been incredibly helpful to me over the last year!
I really hope that someone will be able to implement JWT for Caddy v2. It's a very common technology and your plugin made it incredibly easy to use.

One change I'd like to see is to expand the definition of the User struct to allow passing additional metadata about the user that could then be acted on by subsequent middleware. This would be great for JWT, Paseto, and other formats that pass arbitrary claim information as part of the token.

Absolutely -- I think another caddy 1 plugin (http.login, or loginsrv, I think?) has a User struct with a lot more fields.
And it's probably fine to add more strongly-typed fields too if that is more efficient, especially if they are useful/common in other auth methods.
I am mostly hoping the Authenticator interface is powerful and expressive enough to be compatible with all the various methods of authentication. If someone wanted to look into that for JWT (and others, if they want!), that'd be suuuper helpful. (I'm a bit swamped with other things right now, so. Community effort!)

I did a very straightforward port in https://github.com/roblabla/caddy-jwt/tree/caddy2. It basically works exactly the same way (no fancy starlark integration or anything), but it:

Uses the Authenticator interface instead of ServeHTTP
Delegates all path matching to matcher (removes the path, allow_root, excludes options), simplifying the module a bit.

It's very untested so far. In fact, I had to disable all the unit tests because I couldn't figure out how to make them work yet (still figuring out caddy2). The next step for me is going to be porting loginsrv to caddy2. Once I've got both ported, I'll try getting unit tests back up.

Nice start!
You can actually make it work without any changes to Caddy's source code.
Simply create your own main.go to add the import there instead, then use the order option in your Caddyfile:
{
    order jwt after basicauth
}

I managed to get loginsrv ported over as well. However, I came across a fun little problem:
caddy-jwt and loginsrv have a cool "feature" where loginsrv will automatically generate a random jwt secret if none are set in the Caddyfile, and store it in the JWT_SECRET environment variable. When caddy-jwt later parses its own directive, it will use the secret found in the JWT_SECRET environment variable if none are configured.
Now, this is obviously ordering-dependent. The login directive must be parsed before the jwt directive for this to work. Which, obviously, doesn't really work out reliably well. I'm not sure how caddy parses the directive and how everything is ordered, but when I tried it, caddy-jwt didn't find any JWT_SECRET because it was parsed before loginsrv
So, anyone got ideas to make this work reliably? Is there a way to somehow make the two modules communicate a secret?

Did you try these in your caddyfile:
{
order jwt after basicauth
order login before basicauth
}
It should allow them to be run in the correct order (login before jwt).
Ref: https://github.com/caddyserver/caddy/blob/master/caddyhttp/httpserver/plugin.go#L623

From my understanding, order is an orthogonal concern: it will run the requests through the directives in the prescribed order. My problem has nothing to do with requests though, it's a kinda recey behavior at config parse/module load time. Basically, I need to ensure that loginsrv loads (not executes) before caddy-jwt.
Maybe order also affects other things than request (like Provision/Validate?), but at least the caddyfile parsing is not affected by order.
As a kinda hacky workaround, I'm currently working on lazily loading JWT_SECRET environment variable on first request in caddy-jwt. E.G. instead of grabbing the env vars directly in NewDefaultKeyBackends, have it unconditionally add an EnvVarKeyBackend, which will grab JWT_SECRET and cache its value when it executes its first request. Loginsrv would set the env variable in its provisioning step.
That would work, but is kinda ugly. I wonder if the module lifecycle interfaces like Provision/Validate are affected by order? If they are, I could simply make caddy-jwt fetch the JWT_SECRET in the provisioning step after loginsrv does it, but I'm doubtful that will work.

I wonder if the module lifecycle interfaces like Provision/Validate are affected by order?

Nope -- modules are loaded and provisioned in an order independent of the HTTP middleware/handler chain. But, don't expect one module to be provisioned before another, independent module, for example. If you absolutely need one to be provisioned before another, then perhaps one should wrap/encapsulate the other, and roll their Provision methods into one. Or something like that. It's actually not unheard of, even in Caddy's standard modules, for one module to literally embed another and simply wrap its behavior. If you have a tight coupling of two modules, they should probably be rolled into one or the logic/concerns should be split differently so that they can cleanly be two separate modules.

Alright, I managed to get something that works while keeping the modules separate using the plan outlined above. It's hacky, but everything seems to be working properly so yay \o/.
Thinking about what mholt said, I think jwt should have the ability to load the loginsrv module (or the other way around) using a directive argument, automatically setting up the required configs. E.G. you could have
jwt /* login
# Expands to
jwt /* {
    token-string RANDOM_STRING
}
login {
    jwt-secret SAME_RANDOM_STRING
}

In practice, I think this can be achieved (still keeping the modules separate) by using RegisterDirective (instead of RegisterHandleDirective) and returning two routes in the parseCaddyFile, one for the jwt and one for the login. E.G.
var routes []httpcaddyfile.ConfigValue
// Parse loginsrv part of config
loginsrv_handler := loginsrv.CaddyHandler {}
routes := append(routes, c.NewRoute(nil, &loginsrv_handler)...)
// Parse jwt part of config
handler := jwt.Auth{}
routes := append(routes, c.NewRoute(nil, &jwt_handler)...)

@mholt does that sound reasonable? This would mean that this convenience is only usable from the caddyfile - JSON users would still have to setup both plugins separately, and make sure they pass the same token to both.
And an open questions: Should JWT embed LoginSrv or the other way around?

does that sound reasonable?

Yep, I think so anyway! In fact, that is how the php_fastcgi directive works (and a few others, though I can't recall atm). RegisterHandlerDirective is just convenient if you're making a single route/handler (which most directives do, but most directives are simpler).
You can also remove /* matchers from your Caddyfile, as that's the same as * which is the default anyway:
jwt login

However... before you go down that road...
I would strongly consider integrating with our existing authentication module -- as I mentioned in an earlier comment -- which is designed to support any mode of authentication using this Authenticator interface. If changes need to be made to the interface, let's do that ASAP before we leave beta.
I would love it if you can find a way for it to work with the existing auth module, before we leave beta. You can still make your own directives for the Caddyfile (this is what basicauth does, it integrates with the auth middleware but has its own directive).

Sorry I've been MIA for this discussion recently. I'd strongly prefer that we don't tightly couple this with loginsrv if I have to maintain it. It just makes maintaining both of those plugins more difficult than it should be and potentially more difficult to find security corner cases.
I'd also like it to integrate with whatever existing authentication hooks Caddy 2 has in it via the Authenticator interface. Since this is a security plugin, it needs a hard look at the tests to make sure it's still working as advertised. Honestly I haven't been following Caddy 2 development closely and I'm not up to speed on how the new modules work.

My fork already hooks into caddy’s authentication interface, implementing Authenticator and being in the http.authenticate namespace https://github.com/roblabla/caddy-jwt/blob/caddy2/jwt.go#L78

@roblabla Awesome! Yeah, we can add more fields to the User struct. We can kick it off in a pull request?

@roblabla Awesome! Yeah, we can add more fields to the User struct. We can kick it off in a pull request?

I'll get a PR going.

I'd strongly prefer that we don't tightly couple this with loginsrv if I have to maintain it. It just makes maintaining both of those plugins more difficult than it should be and potentially more difficult to find security corner cases.

The plugins would still be different modules. The only change here is that on the configuration side, there's a shortcut that allows configuring both caddy-jwt and loginsrv at the same time. To explain this better, let me quickly explain how caddy2 modules work:
Caddy2 modules are objects that implements various interfaces, the only two required ones being json.UnmarshalJSON and caddy.Module (though you'd usually implement caddyhttp.Handler as well). A module is "normally" created by deserializing a JSON configuration (through UnmarshalJSON) and installing it at a certain route. More information on routing is available here.
But usually, people don't really touch the JSON stuff. Instead, they're using caddyfile directives. Those are totally decoupled from modules. They're basically a function that returns a list of "ConfigValue", basically asking for various stuff to setup the server the way we want. The list of stuff you can configure through ConfigValue is not well-documented, but looking at caddy's source code basically look at every occurence of sb.pile here, it looks like the values are:

tls.automation_manager: automatic acquisition and renewal of certs, equivalent to setting up something in apps.tls.automation.policies
tls.certificate_loader: Manual cert loading
tls.off: Disables tls for domain
tls.connection_policy: ??
route: Setup a caddyhttp.Handler for the specified route.

Now, with this out of the way, what I'm suggesting is simply to setup a Caddyfile directive that sets up two route handlers, one for caddy-jwt and one for loginsrv. It wouldn't be using any kind of private API or whatever, and would be semantically equivalent to creating two modules sharing the same token. In fact, when dumping the "raw" config from caddy, that's exactly what it would look like.
This should lead to less corner cases. It would allow us to remove the code using environment variables to communicate a token (which is frankly a horrid hack and it's a miracle it currently works at all...).

Since this is a security plugin, it needs a hard look at the tests to make sure it's still working as advertised.

I agree! But I started with getting something that, y'know, works :P.
On the testing side, I mourn the loss of caddy.NewTestController(). It doesn't look like there are any equivalent publicly available. @mholt would it be possible to get something like that, or maybe I'm overlooking something? It seems like all the modules currently in caddy basically just test the module itself, generating a fake request, setting up a Replacer in the request context, and that's it.
That works for unit tests, but it's not really an "end-to-end" test. Caddy-jwt has some nice tests to make sure it properly works on broken paths, and I'd like to keep them, but that means I'd need some way to do complete integration test, creating a complete caddy server from a fake Caddyfile and feeding it fake requests. Do you have any suggestions?

Great writeup @roblabla!
Just a nit: explicitly implementing json.UnmarshalJSON isn't strictly necessary (unless you have some special case going on), you just need json struct tags to adhere to style conventions for the config structure. So the only interface you need to implement is caddy.Module, as well as whatever other interface the host module expects yours to be (for example, caddyhttp.Handler, as you mentioned).

caddyfile directives ... are totally decoupled from modules.

Correct, this is key!

The list of stuff you can configure through ConfigValue is not well-documented,

Yeah, my bad. I will get around to this eventually, I hope.
Basically, Caddyfile directives just throw ConfigValues into a pile (it's literally called pile as you pointed out). Then, when the Caddyfile adapter (the code that transforms Caddyfile into JSON) is building the JSON, it just looks in the pile and pulls out the class of values it needs for that part of the JSON.

tls.connection_policy: ??

Connection policies are used by HTTP servers when answering the question, "How should I establish this TLS connection?" In other words, when a server receives a TLS handshake, it needs to know how to configure that TLS connection, so it looks through its TLS connection policies and uses the first matching policy. It establishes parameters like protocol versions, cipher suites, and more.

On the testing side, I mourn the loss of caddy.NewTestController(). It doesn't look like there are any equivalent publicly available. @mholt would it be possible to get something like that?

Oof, yeah, I need to get around to that. Or somebody needs to make a PR 😅  I am a bit swamped trying to deliver on a few things after being sick for a while.
We're still figuring out the larger testing picture for Caddy 2. I do have a vision, sort of, but again, am constrained by time and funding for now.
I agree with everything you've written though, and it is accurate as far as I can tell.

Thanks for the fast answer mholt! I'll try and see if I can figure something out for the testing. Should I move conversations related to this in https://github.com/caddyserver/caddy/issues/2930 since it seems to be the closest related issue? Or should I open a separate issue specific for integration tests?
I pushed my working loginsrv and caddy-jwt. My next priorities will be making a PR expanding the User struct, setting up some basic unit tests for jwt and loginsrv to at least make sure the basic functionality works, and then exploring the Caddy2 codebase some more to see what would be needed to make integration tests.

@roblabla That issue you linked to is the right one! We can move discussions about testing Caddyfile parsing to that issue.

This should lead to less corner cases. It would allow us to remove the code using environment variables to communicate a token (which is frankly a horrid hack and it's a miracle it currently works at all...).

I think you are misunderstanding what these are for. There has to be some way for users to provide secret key material to this module in order to correctly validate a token.  That is what these options are for.  They aren't for passing tokens, they are for storing secret key material to validate tokens.  If that's not secure, people can easily forge a token with any claims they want.  They shouldn't be part of the Caddyfile because it increases the chances that they will be inadvertently committed.
Also, people don't always use loginsrv and may be using tokens from any number of sources, which is why it provides so many ways to configure the token source so that it will work with all the various auth providers out there.
The problem with coupling them isn't a technical one, it's a process one.  Someone now has to work across both code bases to ensure that a change in one isn't screwing up something in the other one.  I really don't have time for that.  If that's something you want to take on and you feel like you know JWT well enough to make sure this module is secure, I'd be happy to pass it off to you.
I only caution that JWT is a foot gun and it's easy to screw up and create unintended vulnerabilities due to the way the spec is written.

@BTBurke  I think you bring up some good points.

They shouldn't be part of the Caddyfile because it increases the chances that they will be inadvertently committed.

Agreed, we discourage adding credentials to the config directly.
However, in the HTTP basic authentication module, we require that passwords are given in a securely-hashed format. I dunno if JWT secrets need to be in plaintext, but, would hashing them be a possibility?

people don't always use loginsrv and may be using tokens from any number of sources, which is why it provides so many ways to configure the token source so that it will work with all the various auth providers out there.

This is an important point. The Caddy-esque way to handle this is to make the token source a module in the config. So then, perhaps Caddy's JWT authentication module would itself be a host module for token source modules, one of which being loginsrv (or whatever it'll be called).
If the token source is a module, then users can configure any other ways to get the tokens. Sure, maybe they come from env vars. (Maybe the env var names could be configurable in the JSON -- and Caddyfile -- to allow multiple overlapping configs, since we try to avoid global state as much as possible in Caddy 2.) Maybe they come from loginsrv, or any other method.
It'd basically look like this in JSON: https://caddyserver.com/docs/json/apps/tls/automation/policies/management/acme/challenges/ -- notice the "dns" property is modular, and currently has 3 providers (soon to be 20x that many!).
Would that work then? Again, I don't know much about JWT, but it sounds like the Caddy 2 module design is a good way to solve this problem.

I think you are misunderstanding what these are for.

There’s no misunderstanding on my part, only sloppy language. I’m well aware of the intricacies of JWT, and its various pitfalls :).

They shouldn't be part of the Caddyfile because it increases the chances that they will be inadvertently committed.

LoginSrv has multiple options for storing the secret/key either in the config, as a separate file, or if none exists generates a random one and store it in env. Meanwhile, Caddy JWT either takes it from a separate file or an env variable.
I agree storing the token in the Caddyfile is a bit of a footgun, but it’s currently allowed by loginsrv so 🤷♂.

which is why it provides so many ways to configure the token source so that it will work with all the various auth providers out there.

I mean, at the end of the day there are only two ways to pass secrets/keys to caddy-jwt as it exists today: env variable or file path.
My current line of thought is, I’ll disallow passing it inline from a Caddyfile, but at the JSON level the secret will always be stored inline (greatly simplifying the KeyBackend story). This has some implications I need to think hard about though. Notably, the caddy admin API allows dumping the JSON config, so it would be able to dump the secrets, which seems pretty bad... but at the same time it would allow the user to dynamically add new secrets through the caddy admin API, which seems like a genuinely useful feature.
@mholt What’s the threat model like for the admin API? Does it already leak secrets, or should we take care to avoid leaking secret information in it?

Someone now has to work across both code bases to ensure that a change in one isn't screwing up something in the other one.

 But I understand and respect not wanting to take on that risk.
And I know people are using other providers. My primary use-case is with loginsrv, but I will try my best to make sure I don’t unintentionally break other use-cases. The idea behind the tighter coupling between loginsrv and caddy-jwt is to make it more convenient and less footgunny to use them together.

I dunno if JWT secrets need to be in plaintext, but, would hashing them be a possibility?

JWT secrets are HMAC/RSA/ECDSA keys. They can’t be hashed, because the way JWT works is by using that key to sign a string.

So then, perhaps Caddy's JWT authentication module would itself be a host module for token source modules, one of which being loginsrv (or whatever it'll be called).

That’s... actually an interesting line of thought. It’d be interesting to see if it could automatically provision the secret by talking to auth backends. I’ll push it to future work for now though.

Makes sense. I wasn't sure if they were signing keys but I guess they are.

I’ll push it to future work for now though.

Alright, but try to avoid design decisions that can't be compatibly reversed later. Supporting guest modules is easy and only takes about 5 extra minutes. There's even a template at the top of this page that can get you started writing the guest module. And making your module a host module is just a matter of adding a few lines of code and a struct tag. I would encourage just doing it up front and then you have nearly unlimited flexibility from then on without big/breaking design changes. :+1:

It’d be interesting to see if it could automatically provision the secret by talking to auth backends.

Yeah, that'd be awesome. Even if the first/only guest module is very simple (i.e. loading them from env variables), that's OK. Just make an interface you want to contract with and then go with that.

@roblabla sounds like you have some good ideas and a much better understanding of Caddy 2 than I do.  Do you want to take over this module?  If so, I'll wait until C2 is out of beta and then archive this project and point them to your fork.
I really don't have the time or desire to maintain this one anymore since I rarely use JWT.

By the way, if you are thinking about making a module for more general secrets management in Caddy which could be useful for a lot more than just JWT secrets (such as API keys), I think Bitnami's sealed secrets for Kubernetes is a good model.  It uses asymmetric encryption such that keys are safe to include directly in configuration and would only be able to be decrypted by a running Caddy.
It's not quite as straightforward in Caddy because it runs as a persistent kubernetes operator.  You would still have a chicken/egg problem in which Caddy would have to read the decryption key on startup, but that would mean only worrying about how to deal with one secret, but it could be used by other modules that have secrets to protect.  Just an idea.

@roblabla I'm looking at the work you've done on your fork.  Are you thinking of continuing this work?

@derekbassett I mean, it works pretty well already for my use-cases. Here are the TODOs:

Write unit tests. Right now, caddy2 is a bit lacking in this area - a lot of the facilities in caddy1 to help unit testing don't seem to have an equivalent
Integrate the latest changes in Caddy. In particular, populating the caddyauth.User's metadata with the claims.
Fix token source serialization/deserialization. Right now token sources will always use the defaults because its (de)serialization is broken.
Update the README.

There's also quite a bit of cleanup work necessary, for instance a lot of key backends are redundant and could probably be refactored into something a lot cleaner.

Write unit tests. Right now, caddy2 is a bit lacking in this area - a lot of the facilities in caddy1 to help unit testing don't seem to have an equivalent

Oh, right -- you need a way to test caddyfile parsing right?

Yes, that'd be nice

@roblabla I feel like we talked about this before but can't find it, can you point me to what you'd like to see for testing? Or if we haven't gone over that yet, could you tell me what specifically would be helpful?

Sorry for the short answer earlier, I wanted to elaborate but something came up haha.
I feel that the main thing missing to caddy's testing story is an "integration test" kinda thing. I talked about it here

On the testing side, I mourn the loss of caddy.NewTestController(). It doesn't look like there are any equivalent publicly available. @ mholt would it be possible to get something like that, or maybe I'm overlooking something? It seems like all the modules currently in caddy basically just test the module itself, generating a fake request, setting up a Replacer in the request context, and that's it.
That works for unit tests, but it's not really an "end-to-end" test. Caddy-jwt has some nice tests to make sure it properly works on broken paths, and I'd like to keep them, but that means I'd need some way to do complete integration test, creating a complete caddy server from a fake Caddyfile and feeding it fake requests. Do you have any suggestions?

Basically, what I want is something that I can pass a caddyfile as a string, and returns a caddy server object I can call ServeHTTP on with mocked requests so I can make sure it exercises the right paths.

@roblabla Ah, thanks -- I think this is what https://github.com/caddyserver/caddy/issues/2930 is all about, we can move the discussion about this to there.

@BTBurke , @roblabla,  I am wrapping up working on MVP for https://github.com/greenpau/caddy-auth-saml. Upon validation of a provided SAML assertion it issues a JWT token.
As part of the module configuration, I set the following parameters: https://github.com/greenpau/caddy-auth-saml#jwt-token
I was thinking of quickly putting together caddy-auth-jwt, which would re-utilize a lot of code here.
How far away are you with Caddy v2 port? If it is best effort for you, then I will try putting together caddy-auth-jwt in the next couple days. If you have something already, please let me know and I will integrate with what you already have.

@greenpau I have something that works for my use-case at https://github.com/roblabla/caddy-jwt/tree/caddy2, but has a few bugs:

Most importantly, serialization/deserialization of the token source is basically non-functional, which means if a different token source than the default is used, it won't work. That's not too hard to fix, just have to make a wrapping struct around it like I did for KeyBackends.
I never got around to using the caddyauth.User Metadata to store the claims.
And the unit tests are still not ported.

I'm working on this very sporadically though ^^'. Mostly using this for my own use-case and don't have much time to dedicated to anything else right now.

@roblabla , thank you quick reply! I think I will make an attempt at jwt then.

Started in https://github.com/greenpau/caddy-auth-jwt. The skeleton for a configuration is here: https://github.com/greenpau/caddy-auth-jwt/blob/master/123#L23-L59


Update test-suites-and-reports.md

There was an extra "in"

This PR can be CLOSED because i just noticed #23  already has a fix for this

Closing in favour of #23


Fix icons when compiled into a release

Things go horribly awry when an app using ex_effective_icons is compiled into a release. When an input that uses an icon is rendered, or any other use of an icon, the app will throw a stack trace because it is unable to find the svg path that is hardcoded into the Icons module. This fixes that problem.

Thank you, kind sir!!

My pleasure. Thank you for this incredibly useful library.


Doc: Syntax highlight code blocks

Arg, this may break YARD/kramdown. Both YARD and kramdown support GitHub Flavored Markdown (GFM), but in different ways. Also, the official documentation is already syntax highlighted.

Ah, I see.
For me the official documentation is not syntax highlighted. It's just in a code block, but there's no syntax highlighting, hence the PR.
Which other websites is this Readme rendered on, where this change affects it negatively?

I think I screwed up the official documentation link. Should have been: https://www.rubydoc.info/gems/spidr#Examples which does have syntax highlighting.

You're right. Oh well, I'll close the PR then.


Implement FOREGROUD_* colors

This PR implements FOREGROUND_RED, FOREGROUND_GREEN and FOREGROUND_BLUE for #69.

[Current coverage][cc-pull] is 98.52%

Merging [#95][cc-pull] into [master][cc-base-branch] will not change coverage

Powered by Codecov. Last updated by [98fcc78...3d3b6d7][cc-compare]
[cc-base-branch]: https://codecov.io/gh/opalmer/pywincffi/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/opalmer/pywincffi/compare/98fcc7803c7c5e8689f1f4a74ba96cc1f86269b3...3d3b6d741dd6420ade896ab7d22a237ae7e670b9
[cc-pull]: https://codecov.io/gh/opalmer/pywincffi/pull/95?src=pr


PageHeader title left margin set to 16px as per original setting for …

PageHeader title left margin is set to 16px as per original setting for PageHeader. Otherwise you'll note that the PageHeader title text touches the HamburgerMneu pane without a gap.

You are right, but at this point I think that is better if we add ContentMarginProperty

We could also bind the margin of the contentpresenter to the padding property of the pageheader. You could submit a PR


Automatically use current node from environment

Hi!
I am using a project such as https://direnv.net/ to set my environment per directory. I.e. if I change into various project directories where I do coding, I can have an .envrc (or .env) file that gets automatically loaaded on dir change. There are many other similar projects (autoenv etc.).
In regards to this, eslint.runtime is explained like:
  // The location of the node binary to run ESLint under.
  "eslint.runtime": null

Looking at other issues here, it seems I need to set this manually? My question is then, is it not possible for it to load the current Node.js version from the environment if not setting this? I also feel the description for the config above should be more verbose, actually mentioning that it needs to be set if that is not the case.
In addition, I am not sure how to work with actually setting eslint.runtime. This is specific per project. I cannot set it in my user settings, as that would affect all my projects. I also cannot set it the workspace settings, as different users might install it in different locations.
It does seem VS Code properly supports loading the environment: https://code.visualstudio.com/updates/v1_52#_improved-terminal-environment-handling-linux-macos

Have you simply tried to use node as the value. However that needs node to be available through your environment.

@dbaeumer That did fix it. I wonder if that should not be the default really rather than the built-in one?

No, since it would require users to install node to have ESLint support. The direction of VS Code is to work out of the box without any additional executable installs.
I will close the issue.

@dbaeumer But "eslint.runtime": "node" cannot be set in the user settings in VS Code. It is grayed out and hovering over it reports This setting cannot be applied in this window. It will be applied when you open local window..
I agree with that direction, but if a node is found in the environment, then I think it should opt to use that instead of the builtin. I.e. the config eslint.runtime could have a new config basically having an effect like "use environment node if exists otherwise fall back to built-in".
I would have liked to set such a config in my user settings. That is much more intuitive for me, as I have control of my environments node but I do not have control over the built-in node.

You mean having an auto value for the runtime setting?

As your answer was very short, I can only guess what you mean, but I guess yes. Was the problem description in my last post not good enough? The essence is that using a built-in node version is a bad idea if I have one already in my environment. And I cannot set "eslint.runtime": "node" settings (see error above).

I can create a new, better issue for this if wanted with a better description. Will give it a go later.

@thernstig can you describe your setup a little bit more. Since I can set "eslint.runtime": "node".

Hi @dbaeumer sorry for the late reply! There are two separate issues as I see it.

I cannot set "eslint.runtime": "node" in my USER settings. It is greyed out and gives the text This setting cannot be applied in this window. It will be applied when you open local window. when hovering. See here:

If I have a node in my environment, this plugin should use that rather than the built-in one. It is confusing for users to have to configure "eslint.runtime": "node" in settings, as e.g. if you run ESLint via command line, it will not use the same version by default and ESLint via command-line does not bundle any node. There are other reasons.

This issue is about 2) so maybe 1) should be a separately submitted issue.

@thernstig regarding your comments:

this is because you are using some sort of remote setup (WSL, docker, ...) so you have to configure the setting in the corresponding remote user settings file. Best open the settings UI and look for the corresponding remote tab (in the screen shot below it is the WSL Ubuntu tab

we can't since this would result in code execution without user confirmation which according to VS Code's model should be avoided.

@dbaeumer

I am using remote ssh, and I do not have those options (as can be seen in the picture). But I could configure it in the Workspace settings. I'd note that to the same extent I am using Python where this works perfectly fine for the same scenario via e.g. "python.pythonPath": "${workspaceFolder}/.venv" in my User settings.

VS Code Python is adding support for this, see https://github.com/microsoft/vscode-python/issues/12313 i.e. they are adding support to auto-discover the Python env see https://github.com/microsoft/vscode-python/issues/2125

So for Python a) I can set it in my user settings in a similar fashin. b) they are working on auto-discovering the "python" enviroment (and thus binary).
What am I missing? Would this not also be the ideal case for a user in regards to point 2?

Python is different in the sense that VS Code doesn't ship any Python. But even if Python discovers the environment it must ask for user configuration as well since this is what the VS Code model asks for.  Since VS Code ships with Node we use that version as the default since it avoids the user confirmation step for most users.

I will try to rephrase this feature request a bit. I will just focus on one thing then, that would solve most problems.
Feature request
Is it technically impossible to let users set "eslint.runtime": "node" in their user settings, which will work both in local and remote (ssh, wsl, container)? If not techincally impossible, why is it a bad idea? (I do not get the answer about Python for this part, as bundled or not, Python still supports an equal setting for this in user settings i.e. "python.pythonPath": "${workspaceFolder}/.venv".)
What benefits would this bring?

Many of us move between machines, containers, ssh hosts, wsl, into many projects. Setting "eslint.runtime": "node" everywhere, all the time, is time consuming, easy to miss etc. Setting it in user settings would mean I as a user could opt into always using what is in the environment for the current project, no matter where it is located.
Features such as const fs = require('fs/promises'); do not work in the bundled version, since the bundled version is older than what most projects use (version 14 or later). It is also not great to use another version than the environment (project) has in combination with ESLint plugins such as https://www.npmjs.com/package/eslint-plugin-node

Having one setting "eslint.runtime": "node" in the user settings that is used for remote setup is currently not possible due to limitation in VS Code. Declaring node as the default value is nothing I can do due to the fact that users needs to confirm the use of executables.
Hope that explains it.

@dbaeumer it is great explaining why things are what they are, and that is appreciated because you have vast knowledge. So thumbs up!
I do feel though that considering this is a feature request, we are talking about what we want in the future. What should we request in the VS Code repo to get this working then?
Aside: Why is "python.pythonPath": "${workspaceFolder}/.venv" working just fine in user settings? Looks exactly like the same case.

@thernstig you need to request a change to the settings scope management in the VS Code repository that a setting with scope machine-overridable is available even if only defined in a user setting file.
Regarding Python: I don't know. I guess they might use a different scope which doesn't support machine-overridable. But that scope is the recommended scope for settings that point to executables.

Done: https://github.com/microsoft/vscode/issues/119183

@thernstig thanks!

@dbaeumer I just noticed this when using the Settings UI (I usually use the JSON mode):

The info there is incorrect then?

It should read in user/machine setting.

Fix in the description.


Development: Refactor deprecated Spring security configuration

Checklist
General

[ ] I tested all changes and their related features with all corresponding user types on a test server.
[x] This is a small issue that I tested locally and was confirmed by another developer on a test server.
[x] Language: I followed the guidelines for inclusive, diversity-sensitive, and appreciative language.
[x] I chose a title conforming to the naming conventions for pull requests.

Server

[x] I followed the coding and design guidelines.
[ ] I added multiple integration tests (Spring) related to the features (with a high test coverage).
[x] I added pre-authorization annotations according to the guidelines and checked the course groups for all new REST Calls (security).
[x] I implemented the changes with a good performance and prevented too many database calls.
[x] I documented the Java code using JavaDoc style.

Motivation and Context
The currently used Spring security configuration is deprecated and will be removed with Spring Boot 3.0.
Description

Steps for Testing
Prerequisites:

1 User
1 Artemis instance with SAML2 logins enabled

Log in to Artemis with the regular user credentials.
Log out.
Log in to Artemis using the SAML2 login feature.

Review Progress

Code Review

[ ] Review 1
[ ] Review 2

Manual Tests

[x] Test 1
[ ] Test 2

Test Coverage
unchanged

Codecov Report
Base: 75.63% // Head: 75.63% // No change to project coverage :thumbsup:

Coverage data is based on head (2bf495b) compared to base (b27d53d).
 Consider uploading reports for the commit 7d0544d to get more accurate results

Additional details and impacted files
@@           Coverage Diff            @@
##           develop    #5912   +/-   ##
========================================
  Coverage    75.63%   75.63%
========================================
  Files         1117     1117
  Lines        44289    44289
  Branches      8364     8364
========================================
  Hits         33499    33499
  Misses        5621     5621
  Partials      5169     5169

Flag
Coverage Δ

client
75.63% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

The SAML2 and regular login in the Spring 3.0 PR does not work at all with indeed pretty much the same changes. In this PR the SAML2 login works but no more deprecated code is used. So this is an intermediate step between the fix for the broken SAML2 logins that reverted back to the old config (#5721) and the big update that still has to be fixed (#5889).
By merging this beforehand we would decrease the size of the Spring 3.0 update PR and know for sure that the version update breaks stuff instead of the refactoring of the security configuration.

Normal login works, but when using the SAML2 login feature, I get the following:

and whatever I do I cannot even get back to the login page. Tested on TS1.

I'll test it again tomorrow. Maybe I've missed something during testing.

@timo07k @tobias-lippert could you provide some browser logs ?
The endless loop is because of the saml2workflow token . Maybe the initial authentication of SAML does not work for you (redirect from the IdP)

@timo07k @tobias-lippert I just confirmed with @sleiss that the SAML2 setup on test-server1 does not actually allow a login. It is only there to make sure Artemis can start with the SAML2 profile enabled.
One question, though: After which point in the SAML2 login process did this blank page appear?

Click on SAML2-login button on the Artemis login page, so before being redirected to another login page for the external authentication provider.
You were redirected to a external login provider, so after entering your login data and confirming there.

@dfuchss Where can I find the docker image, so I can properly test it as well?

@tobias-lippert it's just this image with the correct tag https://github.com/ls1intum/Artemis/pkgs/container/artemis

The changes to the SAML2 configuration have been integrated into #5889 https://github.com/ls1intum/Artemis/compare/ec94dd7149468e266c5054001a518eb4c74324b8...4f1b241a2ea91a0edb1176b4e6701de92018d0b8


[api-docs] docs(ErrorCodes): added 20035

A new commit was made into the api-docs repo. This issue was created automatically. Need to review if we made any change to the library for this commit.
https://github.com/discord/discord-api-docs/commit/d090c0b3dad2f3d35b603f916809ab9152884029

Done


support set column object and retrive column index

I created this PR to make avaialable columnIndex binding beforeCellBind and support set column item when is creating a dynamic column, like:
  <iron-data-table id="table" items="{{items}}">
    <data-table-column name="Fixed Column">
      <template>
        <foo></foo>
       </template>
    </data-table-column>
    <template is="dom-repeat" items="{{dynamicColumns}}" as="columnItem">
      <data-table-column column-item="{{columnItem}}">
        <template is="header">
          <bar></bar>
        </template>
        <template>
          <foo></foo>
        </template>
      </data-table-column>
    </template>
  </iron-data-table>

This change is

Ow, this is the solution I was looking for...

Thanks to perform this solution bro.

Hi there! Sorry for the delay!
The columnIndex looks like a nice addition, thanks!
However, I'm not sure if the columnItem is needed – since all the column properties are available inside beforeCellBind(data, cell) by using data.column.foo right? Or am I missing something?

Hi Saulis, no problem, thanks for your attention!
I suggested columnItem because today we only have row item available to use two way data bind, there aren't a collection items for columns as we have for rows, because we always have created static columns until now. :)  I don't know if is possible solve this using beforeCellBind, do you know?
For dynamic columns we need to set what column item we want to use in two way data bind for each data-table-column.
If it isn't look good, what do you think about create a new element like data-table-columns with items property, so we can do a dom-repeat inside the element instead do it outside?
Thanks again.

@andrew-silva-movile hmm not sure if I'm missing something.. can you post some example code for the use case?
The reason why I'm a bit confused is that in the PR the only change that columnItem property makes is that it will be available through cell.columnItem inside beforeCellBind(data, cell) right? However, you can already access the same property today by using data.column.columnItem without adding any new bindings?


regarding font change.

Hi,
I am facing some issues in mathJx. When I have not selected any font from wiris editor and it's rendering through mathJx it's not showing the proper font that I have selected from wiris editor.
For example:
From wiris editor:

passing the math HTML:

<math xmlns=\"http://www.w3.org/1998/Math/MathML\"><mi>a</mi><mi>w</mi><mi>s</mi><msqrt><mn>23</mn><mi>a</mi><mi>w</mi><mi>s</mi></msqrt></math>

Rendering from mathJx:

If you see the font is different.
I have used CDN:
https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?config=TeX-MML-AM_CHTML
Please help me to get the same font.
Thank you.

I am waiting for your update.

MathJax only supports a limited number of fonts (MathJax needs to know a lot of information about the font, and that has to be build into MathJax; data is available only for a handful of fonts).
Note that the MathML that you are passing to MathJax contains no font information at all, so MathJax will use its default font (or the one that you include in your MathJax configuration, which you have not provided).  It is possible to add fontfamily="sans-serif" to the <math> element, but this will likely lead to poor layout (MathJax doesn't have the bounding box information about the font) and slow rendering (MathJax will have to try to measure the widths of all the characters, which causes page reflows).  So this is not a great approach.
There is a description of how to configure MathJax to use sans-serif fonts for text that you might be able to use if you are only concerned with using sans-serif for letters and numbers, but don't care too much about which sans-serif font it it.


No versions available for org.seleniumhq.selenium:selenium-support:jar:[2.53.0,4.0.0)

in pom.xml I connect dependence.
according to the instruction from the website http://ru.selenide.org/quick-start.html

com.codeborne
selenide
4.4.1
test

When I begin assembly of maven I receive a mistake
"Failed to execute goal on project dashboard-web: Could not resolve dependencies for project atc.cm:dashboard-web:war:1.0-SNAPSHOT: Failed to collect dependencies at com.codeborne:selenide:jar:4.4.1 -> org.seleniumhq.selenium:selenium-java:jar:3.3.1 -> org.seleniumhq.selenium:htmlunit-driver:jar:2.24 -> org.seleniumhq.selenium:selenium-support:jar:[2.53.0,4.0.0): No versions available for org.seleniumhq.selenium:selenium-support:jar:[2.53.0,4.0.0) within specified range -> [Help 1]"
What's the problem?
Earlier I used the  4.0 version

@vitassecuriti Why closed? Have you found a solution? Can you share it with others?

I have created the new project, I have prescribed dependence, I have started the test - everything works.
I have come to a conclusion that it is a problem in the conflicts of my dependences. And on this I have decided to close this question not to distract you from the solution of real problems.

Ok, thank you for caring about us :)
On Mar 31, 2017 9:08 AM, "TaliK"<EMAIL_ADDRESS>wrote:

I have created the new project, I have prescribed dependence, I have
started the test - everything works.
I have come to a conclusion that it is a problem in the conflicts of my
dependences. And on this I have decided to close this question not to
distract you from the solution of real problems.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/codeborne/selenide/issues/509#issuecomment-290625502,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AARE3USiVTg_hvmVSlv3yV0pe9_vVTQZks5rrJhRgaJpZM4MumBy
.

Hello! If you read it in 2022.
Same problem was when i started project with "Selenium UI Testing" plugin, chouse "selenium 4" and add latest appium version to dependencies in gradle. Solve problem when downgrade to "selenium 3"

Yes, currently the latest appium version doesn't support Selenium be 4 yet. Need to wait another major update of Appium.


Updated VisualBasic Project

Converted CSharp project into VisualBasic project.

Accepting the full version of DBLess examples in both C# and VB.NET.


Register custom fields from FormFieldBlueprint

#26674 added a FormFieldBlueprint, but the results of registering a custom field extension this way were not yet reflected in the useCustomFieldExtensions hook that the scaffolder uses. This updates the hook to pull custom fields from either registration method (React tree or blueprint).
Since the hook is in scaffolder-react, I moved the formFieldsApiRef to this package, so as not to introduce a backwards dependency. The registration of the default API is still done in the scaffolder package.
:heavy_check_mark: Checklist

[x] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[x] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[x] All your commits have a Signed-off-by line in the message. (more info)

Thanks for cleaning this up, @benjdlambert! 🙇

No worries - I ended up using apiHolder.get(..) as this broke a load of tests if you didn't have the routeRef already provided, I wanna fix up those tests and go back to using useApi(formFieldApiRef) instead, but also wanted to get it in this release to unblock you.

So I will probably update this over the coming days 👍


Graphql example

Coverage remained the same at 100.0% when pulling 11e3341974014670659a5882bb20ab94f492f7d6 on graphql into 278375cae93c0655b18a0d10e75626a8478a733e on master.

fixes #780


Reset toggles on Safari not working as expected

Safari and possibly FF (to look into) aren't behaving the same as Chrome on "Reset all toggles". Where Chrome deletes them, Safari sets them with an empty value.
It won't impact functionality as we look at if the value is true, but it does affect the error message as we only look at if the toggle is there.
Reckon we should use deleteCookie instead of setting it with an empty value.

Fix has been deployed


[#4679] fix resource message when non HS authors

Resolves #4679
Pull Request Checklist:

[X] Positive Test Case Written by Dev

[ ] Automated Testing

[ ] Sufficient User and Developer Documentation

[ ] Passing Jenkins Build

[ ] Peer Code review and approval

Positive Test Case

Create a new resource.
Add an author that is not a HydroShare user
Remove any authors that are HydroShare users
Incorrect "No active HS users..." message no longer shows in the "Authors:" section of the resource header

METRIC
VALUE

https://sonarqube.cuahsi-workstation.com:9000/dashboard?id=hydroshare-4684

thanks!


Add support for a config

Install directory (allows running from anywhere)
keep memory of resolution/position of application
etc

https://pypi.org/project/appdirs/ could be useful for this
install directory could be auto discovered on windows from registry https://gist.github.com/iojon/8a241ba33cc81764916378d033e9d5a5

https://pypi.org/project/appdirs/ could be useful for this
install directory could be auto discovered on windows from registry https://gist.github.com/iojon/8a241ba33cc81764916378d033e9d5a5

This has been completed for a while


[BACKLOG-11030] DET Play button still active when not displayed

Build Completed
:fire: This pull request has some issues. It would be preferable to fix them in order for it to be just perfect. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
ant -Dtestreports.dir=bin/reports/unit-test -f engine/build.xml clean-all resolve jacoco && ant -Dtestreports.dir=bin/reports/integration-test -f engine/build.xml jacoco-integration checkstyle publish-local

Cleanup Commands
rm -r ~/.ivy2/local || echo no publish local to remove

Changed files
  engine/src/org/pentaho/di/trans/TransPainter.java

Unit test coverage change
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.
org.pentaho.di.core.auth.core.impl.DefaultAuthenticationConsumerFactory

Branch Change:  + 7.14%
Complexity Change:  + 7.69%

org.pentaho.di.job.entries.evalfilesmetrics.JobEntryEvalFilesMetrics

Branch Change:  + .39%
Complexity Change:  + .51%
Instruction Change:  + .08%

org.pentaho.di.job.entries.evaluatetablecontent.JobEntryEvalTableContent

Branch Change: -1.01%:small_red_triangle_down:
Complexity Change: -1.06%:small_red_triangle_down:
Instruction Change: -.17%:small_red_triangle_down:

org.pentaho.di.job.entries.getpop.MailConnectionMeta

Branch Change:  + 1.00%
Complexity Change:  + 1.41%
Instruction Change:  + .30%

org.pentaho.di.job.entries.waitforsql.JobEntryWaitForSQL

Branch Change:  + .66%
Complexity Change:  + .93%
Instruction Change:  + .13%

org.pentaho.di.trans.step.StepMeta

Instruction Change: -.19%:small_red_triangle_down:
Line Change: -.27%:small_red_triangle_down:

org.pentaho.di.trans.steps.csvinput.CsvInputMeta

Instruction Change:  + .05%

org.pentaho.di.trans.steps.dbproc.DBProcMeta

Instruction Change:  + .11%

org.pentaho.di.trans.steps.groupby.GroupByMeta

Branch Change: -2.08%:small_red_triangle_down:
Complexity Change: -2.11%:small_red_triangle_down:

org.pentaho.di.trans.steps.memgroupby.MemoryGroupByMeta

Branch Change:  + 2.35%
Complexity Change:  + 2.70%
Instruction Change:  + .18%
Line Change:  + .48%

org.pentaho.di.trans.steps.replacestring.ReplaceStringMeta

Instruction Change:  + .07%

org.pentaho.di.trans.steps.rowgenerator.RowGeneratorMeta

Instruction Change:  + .08%

org.pentaho.di.trans.steps.sortedmerge.SortedMergeMeta

Instruction Change: -.18%:small_red_triangle_down:

org.pentaho.di.trans.steps.symmetriccrypto.symmetriccryptotrans.SymmetricCryptoTransMeta

Branch Change:  + 3.33%
Complexity Change:  + 1.85%
Instruction Change:  + .28%

org.pentaho.di.trans.steps.tableoutput.TableOutputMeta

Branch Change:  + .91%
Complexity Change:  + .82%

org.pentaho.di.trans.steps.textfileinput.TextFileInputMeta

Branch Change: -.53%:small_red_triangle_down:

org.pentaho.di.trans.steps.uniquerows.UniqueRowsMeta

Instruction Change: -.18%:small_red_triangle_down:


correct database name for docker-compose installation.a few badgets

Are all badgets necessary?
docker-compose database service name correction is ok.


ubuntu or windows

您好，请问这个是在ubuntu系统下运行的吗，在windows下可以运行吗

The code was tested in Linux environment. I'm not sure whether it can be run in Windows.


make button dependent specifically for map (if ends up harder than the rest)

closed with https://github.com/mealoise/Surprise_Map_Recreation/commit/b9db94d2030484cc986e257783eeda6be13dc93a


Don't see particles

Spark link
No errors , but spark link, i think is can't help with this issue, but take it: https://spark.lucko.me/mP3ZFmutJi
Plugin Version
1.12x
Server Version
1.20.6
Server Platform
Purpur
Describe the bug
Hi , i have problem with block particles, i don't see effects, it's just dissapear in 1 moment. I will give you info, i think, maybe, it is conflict with other plugins , but i didn't know, with which.
Steps to reproduce
Idk, it's just dissapear in one moment.

[X] I ticked all the boxes without actually reading them
[X] My version of Minecraft is supported by CrazyCrew.


Correctly look at the settings for the resource in question when calculating working directory.

For #8561

[x] Pull request represents a single change (i.e. not fixing disparate/unrelated things in a single PR).
[x] Title summarizes what is changing.
[x] Has a news entry file (remember to thank yourself!).
[x] Appropriate comments and documentation strings in the code.
[ ] Has sufficient logging.
[ ] Has telemetry for enhancements.
[ ] Unit tests & system/integration tests are added/updated.
[ ] Test plan is updated as appropriate.
[ ] package-lock.json has been regenerated by running npm install (if dependencies have changed).

Drat, ran into Rich's change in kernel.ts. Will update....

Codecov Report

Merging #8680 (af6f197) into main (a8c3c3a) will increase coverage by 0%.
The diff coverage is 100%.

@@          Coverage Diff          @@
##            main   #8680   +/-   ##
=====================================
  Coverage     71%     71%
=====================================
  Files        384     384
  Lines      24651   24651
  Branches    3792    3791    -1
=====================================
+ Hits       17632   17640    +8
+ Misses      5476    5470    -6
+ Partials    1543    1541    -2

Impacted Files
Coverage Δ

...lient/datascience/jupyter/liveshare/serverCache.ts
83% <ø> (ø)

src/client/datascience/jupyter/kernels/kernel.ts
75% <100%> (ø)

src/client/datascience/utils.ts
47% <100%> (ø)

.../client/datascience/errors/sessionDisposedError.ts
60% <0%> (-40%)
:arrow_down:

src/client/datascience/baseJupyterSession.ts
75% <0%> (-1%)
:arrow_down:

...lient/datascience/jupyter/kernels/cellExecution.ts
77% <0%> (+<1%)
:arrow_up:

src/client/datascience/raw-kernel/rawSocket.ts
84% <0%> (+1%)
:arrow_up:

src/client/datascience/dataScienceSurveyBanner.ts
75% <0%> (+6%)
:arrow_up:


upstream: fix segfault in http health checker

Description: The http health checker would occasionally segfault due to trying to
close an already closed connection after a health check timeout. This
adds a null check before trying to do so.
Risk Level: Low, small bug fix
Testing: Unit test
Docs Changes: n/a
Release Notes: n/a
Fixes #4351

Not sure what's causing the coverage failure (saw a similar issue on another PR). Running ci/run_envoy_docker.sh 'ci/do_ci.sh bazel.coverage' shows this error:
[ RUN      ] IpVersions/ListenerImplDeathTest.ErrorCallback/IPv6
test/common/network/listener_impl_test.cc:63: Failure
Death test: errorCallbackTest(GetParam())
    Result: threw an exception.
 Error msg:
[  DEATH   ]
[  DEATH   ] test/common/network/listener_impl_test.cc:63:: Caught std::exception-derived exception escaping the death test statement. Exception message: cannot bind '[::1]:0': Ca
nnot assign requested address
[  DEATH   ]
[  FAILED  ] IpVersions/ListenerImplDeathTest.ErrorCallback/IPv6, where GetParam() = 4-byte object <01-00 00-00> (3 ms)

@snowp  git commit -s --allow-empty -m 'Kick CI' && git push to trigger the CI  kick-ci

Typically, behavior that's different in coverage tests is related to the fact the logging is set to trace level by default. You can check for that by adding --test_arg="-l trace" to your bazel comand.

@zuercher Oh nice, that's helpful. I think the build failure is due to #4396, and the different log level would support that.

Bumping to get rid of stalebot. I'm still planning on landing this when I get time, hopefully this week.

@snowp do we want to land this for 1.8.0? Is there more work to do here or do we just need a review?

My question on this boils down to whether there was a way to test it without exposing active_sessions_ in HealthCheckerImplBase. Otherwise, it seems pretty straightforward.

I tried to use the suggested interface instead at some point but it blew up in my fact (can't remember the exact details). I haven't had time to revisit

Updated to use client_connections_ in test, PTAL


Use codepen demos in docs?

Vue 3 docs will use codepen, I believe, for the examples, so people can try it out. I wonder if this is something we could do, too, and if that would be a good idea.

I was thinking about this the other day, too. Right now, the API page looks a bit too bloated given that we always need to provide a Component + a spec file (or more).
However, I would wait until docs team agrees on a solution to display code snippets, and then stick to it. Until then, I'd say we keep writing code snippets using markdown blocks, which I think make porting them to other platforms quite easy.

Sounds good to me. There is still be too much going on atm on the API page... maybe we can find a cleaner way. Either way, maybe this discussion should be in the docs repo.


Add option for per-team animations

This PR extends the script added in #291
This adds an additional option choice to include teams' match animations in their archives. Since every archive will now include the texture files the resulting combined archive is substantially larger.
The matches to include is determined by extracting the match numbers from the log names, as such matches are added as each log is processed.
ZIP_DEFLATED is used for the archives since the animation data is highly compressible and this keeps the overall archive size down.
While it's possible that we choose not to insert the animations into the archives at this point in the chain, this code stands as an example of how team-specific animations can be generated later in the chain.

It's also possibly worth keeping this to allow us to generate all types of team zips for manual distribution.

It's also possibly worth keeping this to allow us to generate all types of team zips for manual distribution.


Howto: run multiple clusters.

I'm looking for confirmation that tack can be used to run multiple clusters in one AWS account, in such a way that one cluster can be cleaned, leaving the other cluster untouched.
This does require an amount of terraform state file handling and I plan to use terragrunt for that.  Happy to provide a PR, if that's of use.
Mainly I want to be confident that a make clean is safe and that nothing is shared between the two clusters spun up with different names (security groups for example).

I probably should also mention that I'm a big fan, and have had better results with Tack than I've had with Kops or Kube-aws so far, so thank you.

I run multiple clusters in one AWS account, using tack but I modified tack for storage terraform state in s3. I think that terragrunt can work fine.

Hi all,
I created a modified version of tack where we can easily create multiple clusters.
It is same with normal tack except you have to provide a cluster config before running make.
E.g. ENV=prod make all or (make all ENV=test)
Generated files of each cluster will be put under a sub folder of ./build
E.g. build/name.toplevel.domain
I can send a pull request if we find it useful.
https://github.com/lexhung/tack/blob/master/Makefile
https://github.com/lexhung/tack

Thanks for the links @lexhung.
@lexhung the diff here is quite big: https://github.com/kz8s/tack/compare/master...lexhung:master
Are all those changes required for running multiple clusters in one account, or is it just 8a83ab93398e99eab214151dbdc5798edf60e64d and 3b9a34f4587f1e1630e4dde4e0b278dd157d3fe2?

For what it's worth, Terraform will provide environments in 0.9. This is still in beta and in 2 months I expect a release.

@cemo do you have documentation on environments?

@owenmorgan check this PR and related files:
https://github.com/hashicorp/terraform/pull/12366/files

@mcameron Besides enabling multi cluster, the changes here are:

putting the paths into variables (so I can better track/switch the filepaths of each cluster)
using a single source of terraform output (see .tfstate task in makefiles/terraform.mk) so we don't have to run terraform output everytime we need those values.
plug directory variables into terraform config ("build-dir", "dir-tmp", "dir-ssl", "dir-keypair")
a few tweaks for my particular use case (e.g. disable busybox-test, VPC rule warning, ...) which I can revert for the pull request.

@owenmorgan Terraform 0.9 is released.

Thanks


Where I can find the 'config' options?

Hi,
where I can find the 'config' options? Because based on my testings scrollbar can work without putting dimensions into config but it won't work without 'scroll : (...)'. Where I can find the list of parameters? And the ones that are needed and not needed?

Unfortunately the scroll doesn't seem to update on it's own in my project when content is added so I have to use other script, kinda sad but I don't have time to troubleshoot that. Other than that great script.

hey,
It's wierd because the scroll should update whenever you are using the appendTo method.
But since it doesn't, you can use the refresh() method.

Hi, where I can find the 'config' options? Because based on my testings scrollbar can work without putting dimensions into config but it won't work without 'scroll : (...)'. Where I can find the list of parameters? And the ones that are needed and not needed?

So, i updated the code and fixed a little bug where it assumes the default configs when you do not provide any configuration.
From now on, the only required option is the "selector", other than that... it will assume the default values wich are:
const defaults = {
    selector : 'given ID', <-- Required
    config : {
        dimensions : {
            width : "100%",
            height : "500px"
        },
        scroll : {
            bottomOffset: 0,
            autoHide: false
        }
    },
    onComplete: function(){},
    onEnd: function(){},
    onTop: function(){},
    onMove: function(){},
    onDragStart: function(){},
    onDragStop: function(){},
    onTouchStart: function(){},
    onTouchStop: function(){}
};

hey,
It's wierd because the scroll should update whenever you are using the appendTo() method. But since it doesn't, you can use the refresh() method.

I'm not using this method, sorry, I'm not great at JS. You made good working script but unfortunately not for my usecase.
https://flyingatom.com/testowanie/scroll/ - here, I setup a demo with your script and MiniBar.
You can see what I mean by checking 'Kantor' checkbox and then scroll - you will see that your scrollbar stops at like 75% even though it is the end of the box.


[AIRFLOW-2457] Update FAB version requirement

Make sure you have checked all steps below.
JIRA

[x] My PR addresses the following Airflow JIRA issues and references them in the PR title. For example, "[AIRFLOW-XXX] My Airflow PR"

https://issues.apache.org/jira/browse/AIRFLOW-2457
In case you are fixing a typo in the documentation you can prepend your commit with [AIRFLOW-XXX], code changes always need a JIRA issue.

Description

[x] Here are some details about my PR, including screenshots of any UI changes:
Update FAB version requirement to support timezone

Tests

[x] My PR adds the following unit tests OR does not need testing for this extremely good reason:
Ran setup.py locally

Commits

[x] My commits all reference JIRA issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

Documentation

[x] In case of new functionality, my PR adds documentation that describes how to use it.

When adding new operators/hooks/sensors, the autoclass documentation generation needs to be added.

Code Quality

[ ] Passes git diff upstream/master -u -- "*.py" | flake8 --diff

Codecov Report

Merging #3349 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #3349   +/-   ##
=======================================
  Coverage   76.22%   76.22%
=======================================
  Files         198      198
  Lines       14788    14788
=======================================
  Hits        11272    11272
  Misses       3516     3516

Continue to review full report at Codecov.

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


[IS Analytics] Authentication step listed as failure in local login attempts page

Description:
When a login is done through IS a step with failure is listed.
Suggested Labels:

Suggested Assignees:

Affected Product Version:
OS, DB, other environment details and versions:
Steps to reproduce:
Related Issues:

@dilin993 Will you be able to add more details please.


Log info when ignoring buildpacks or builder in descriptor

@samj1912 It would be great if you could review this PR 🙂

Resolves https://github.com/pivotal/kpack/issues/704


Add Silverpeak to LF-Edge lanscape

Add logo and metadata for Silverpeak

HPE has announced an intent to purchase them...

putting this in Networking/networking- the do WAN

item:
name: Silver Peak
homepage_url: 'https://www.silver-peak.com/'
logo: 'https://upload.wikimedia.org/wikipedia/commons/5/54/Silver_Peak_logo.svg'
crunchbase: 'https://www.crunchbase.com/organization/silver-peak'

PR #375


Support for blend modes [enhancement]

Have you considered implementing Blend Modes for drawing objects/text, as defined in Section 11.3.5. and Table 136 (page 324) of the pdf_specification.pdf?

Hey @Hopding
I looked around your code, and I got this feature working.
I introduced new (optional) property named blendMode in all of the PDFPageDraw[xxx]Options  and new operator BlendModeOperator = 'BM',
I did some (manual) testing, and it seems to be working ok.
Changed files are attached. If you would like, I could PR and continue on this... or someone else can take over,
blendModes.zip

Hello @bockoblur!
Looks like you're on the right track! It'd be great if you could open a PR for this. I'd be happy to get this feature added! (note that you'll need to update the integration tests to use this feature before the PR can be merged).
Let me know if you have any questions!

Opened PR (#503 - Add Blend Modes)
I am having trouble running apps/tests for Node & Deno on my Windows PC.

What exactly is giving you trouble @bockoblur?

When I run the app:node or app:deno scripts, 1st test completes, but system cannot open resulting file. File is generated ok, and I can open it manually from system temp folder, but script halts on error and would not continue.
I wrote new test (test14.ts) for Node and Deno, and it generates a good pdf file demonstrating the new functionality (blendMode) when run separately.
At first I thought that problem is with path separator ('\' on Windows instead of '/'), but I changed that in Node script (now uses path.sep) and still no luck. Same error occurs in Deno.run when running app:deno.
Maybe someone could try the tests on Mac or Linux?

@bockoblur Just pushed https://github.com/Hopding/pdf-lib/commit/ff447a9d7164f0b5e45c99fc884e79b1d22890e7 to fix those issues on Windows. The integration tests should run seamlessly for you now

Closing as this feature was added in https://github.com/Hopding/pdf-lib/pull/503.

Version 1.9.0 is now published with this feature. The full release notes are available here.
You can install this new version with npm:
npm install<EMAIL_ADDRESS>
It's also available on unpkg:

<EMAIL_ADDRESS><EMAIL_ADDRESS>
As well as jsDelivr:

<EMAIL_ADDRESS><EMAIL_ADDRESS>


process document self-closing and non self-closing node

New Feature Proposal
Description
if a document contain self-closing and non self-closing node
when format then all is non self-closing node
Background
if a document contain self-closing and non self-closing node
when format then all is non self-closing node
Specification
In case of updates that adhere to specification changes, please reference the used specification.

Sorry I can't follow - can you please give an example @jiangpan ?
Keep in mind that we follow the W3C specification - thus we cannot just change how the HTML is interpreted / DOM is generated.


Update xray-core version to latest

The current version of teddysun/xray xray-core seems a bit outdated (1.8.4), could you please update it to the latest version (1.8.16)?
Again, thanks for this awesome script!

I suggest you to switch to sing-box. Everything should work as before and you will have more features.
We are going to drop xray support.


fix: unique module name for opentelemetry example

Update the opentelemetry example so that it has a unique module name. Currently this example has the same name as the basic example (github.com/uptrace/bun/example/basic) which creates a namespace collision and may break some tools, such as gopls in experimental module mode.

Thanks


Type guard not work in union type of objects

TypeScript Version:  <IP_ADDRESS>33

Search Terms:
type guard, union type of objects, typeof
Code
function fn(i: { foo: string, bar: number, baz: boolean } | { foo: number, bar: boolean }) {
    // Notice: i.foo has two different types in intelligence and after written down.
    if (typeof i.foo === 'string') {
       // as screenshot, in intelligence, 'i.foo' is of type 'string | number'
        i.foo // after written down, i.foo becomes 'string'
        i.bar // always 'number | boolean'
    }
}

Code 2
function fn(i: { foo: string, bar: number, baz: boolean } | { foo: number, bar: boolean }) {
    // NOTICE: we added parenthesis
    if ((typeof i.foo) === 'string') {
        i.foo // string | number

        i.bar // number | boolean
    }
}

Expected behavior:
in 'if' branch, ‘i’ should be { foo: string, bar: number, baz: boolean }
Actual behavior:
As comments says.

Playground Link:
http://www.typescriptlang.org/play/index.html#src=function fn(i%3A { foo%3A string%2C bar%3A number%2C baz%3A boolean } | { foo%3A number%2C bar%3A boolean }) {
    if (typeof i.foo %3D%3D%3D 'string') {
        i.foo %2F%2F string | number
        i.bar %2F%2F number | boolean
    }
}

The type of foo inside the if is string so the type guard does work on that field as it should.  The code completion entry does not show the flow type (might be the topic of a different issue), but if you try to . into foo you will see it is a string.
Narrowing the parent object is only done in specific scenarios, when the property is considered a discriminant for the union. A property is considered as a discriminant property if:

The property is a literal type as outlined here #9163
The a property of a union type to be a discriminant property if it has a union type containing at least one unit type and no instantiable types as outlined here #27695

Might be other scenarios that I haven't quoted here, but the scenario in the code is not covered by any as far as I can tell.
As a side note, you can discriminated the union in the example using an in type guard:
function fn(i: { foo: string, bar: number, baz: boolean } | { foo: number, bar: boolean }) {
    if ('baz' in i) {
        i.foo // string
        i.bar // number
    }
}

Or use a custom type guard.

@dragomirtitian I have a question on why TS doesn't provide us the typeof guarding on codes above? Is there an underlying unsafe situation?

@zheeeng  These cases must be specifically crafted to work, they don't just happen. I am not sure there is a definitive answer as to why more cases are not considered as property discriminants but @ahejlsberg mentions in the original discriminated union PR in a response to a similar request to yours that:

One concern is how this would affect performance. It seems that for every reference to x in a control flow graph we would now have to examine every type guard that has x as a base name in a dotted name. In other words, in order to know the type of x we'd have to look at all type guards for properties of x. That has the potential to generate a lot of work.

The lack of narrowing isn't because the type of foo is not a discriminant type; a typeof type guard has never discriminated union types. Are there compelling use-cases where narrowing would be desirable? In my limited experience I've never bumped into this limitation.

@jack-williams

... a typeof type guard has never discriminated union types. Are there compelling use-cases where narrowing would be desirable? In my limited experience I've never bumped into this restriction.

As a newbie, this can be confusing. For example, when I look at this stackoverflow question, the code looks like it should compile (to me).
The official documentation has a section for nearly every form of JavaScript "narrowing" I can think of. Then it goes even further, providing TypeScript-only solutions like Type Predicates.
From my perspective, the most compelling reason to implement this is to make the language feel consistent. Currently, typeof not discriminating unions feels like an arbitrary restriction that will surprise most people that run into it for the first time.
Now having said all that, I just wanted to answer your question since nobody else did. In my opinion, this might be more of a documentation issue than a problem with the language. And for that reason, I plan to open a separate issue.


Widen Comment Section of Recipe Comments

Suggestion
Currently Recipe Comments Sections are really small. It's really hard to write long sentences. See below:

It would be better to make it either;
1- Adding a new setting to manual adjusting of Recipe Comments Section Length by Players.
2- auto-adjust Recipe Comments Section Length depending on Resolution and/or GUI scale.
1st one would be much better and easier in implementation both as Author and Players.
If possible Height Modifications to Text Box would be awesome as well.
Thanks for this awesome mod.
-udkudk

Hello, thanks for the suggestion. Adjusting it dynamically is really difficult, there's not a good way to know how much empty space there is. Adding adjustability is just too much, this is a very niche feature, so I'll have to leave it as-is as a good middle ground.


Unpublished events, sending duplicates on application startup in some cases

when spring.modulith.events.republish-outstanding-events-on-restart=true
and a bean, using this scheduler (code below) to republish incomplete events exists at the same time. it will produce two duplicate events (duplicate the data atleast) of the unpublished/incomplete events from EVENT_PUBLICATION on application startup.
  @Scheduled(fixedDelayString = "${events.resubmitFrequencyInSecs}", timeUnit = TimeUnit.SECONDS)   void resubmitUnpublishedEvents() {     incompleteEventPublications.resubmitIncompletePublicationsOlderThan(         eventsConfigProperties.getResubmitOlderThan());   }
Tested with externalized events to an azure eventhub (using kafka apis).
But also on a local kafka container.
in fact, when calling incompleteEventPublications.resubmitIncompletePublications(eventPublication -> true);
from a test using @ApplicationModuleTest, it will produce 3 similar events pr unpublished event. (1 for resubmit on startup, 1 from the scheduled bean, and 1 for the test)

The property mentioned is documented not to be used in a multi-instance scenario:

Usually not recommended in multi-instance deployments as other instances might still be processing events.

That said, any kind of (At)scheduled operation will need some sort of distributed locking (usually in the form of Spring Integration distributed locks or ShedLock) to make sure the individual application instances do not compete for work or resources. This is not a problem specific to Spring Modulith.

In fact, when calling incompleteEventPublications.resubmitIncompletePublications(eventPublication -> true);
from a test using @ApplicationModuleTest, it will produce 3 similar events per unpublished event. (1 for resubmit on startup, 1 from the scheduled bean, and 1 for the test).

That's “correct” in the sense that that's the result of your code and setup triggering the functionality three times.

If the republishing used pessimistic locks (select for update) this can be avoided.

A simple SELECT FOR UPDATE is unfortunately not going to cut it, as that would mean unconditionally wrapping the event listener into a transaction that'd consume a database connection. As we don't know how long the listener execution is going to take, that would be a recipe for exhausting the connection pool accidentally. There are plans to revamp the current event publication lifecycle to provide more specific means to obtain and manage publications.

My memory puzzled me - I thought the scheduling was done by modulith, but we actually do this ourselves - so yes, then we can add shedlock to protect it from concurrency.


cargo file-lock dead-lock in build.rs to get metadata:

when you try compile your project with cargo build,
then your build.rs generates a binary by rust compiler, and that is called by cargo package manager,
but cargo itself already has a lock on some files located at ~/.cargo/registry/ (may),
so vergen calls cargo metadata --format-version 1 to get the metadata for the crate.
This is never done. This process can never end, because at the moment the down-stream project's compile command (such ascargo build) is waiting for the build script to finish, and vergen is waiting for the cargo build to release the file lock.

what happen?
see following screenshots:

It's probably very rare, and now it's suddenly works again, so leave it as an FYI, vergen calls the cargo command internally anyway... I personally don't think this is a good design


Switch back to Python 3.x and revert Python 3.11 hack

For https://github.com/pkgcore/pkgcheck-action/issues/13, we switched to hardcoding 3.11 temporarily in 966e2235b9f86bf5f2af17cdffbb6d8bb59ddb16. We should undo that and properly support newer Pythons in the action.

I think upstream tree-sitter python should move the distutils imports into the build_library() function and then all this would be solved as this action should be using the binary wheel with a pre-compiled tree-sitter bash library so no compiling at runtime is necessary if everything is set up correctly.

Yet another option is making the action depend on another wheel providing pre-compiled tree-sitter-bash support which is a decent alternative if upstream tree-sitter is the maintainer for the wheel. There does appear to be third party wheels for various tree-sitter language support as well as one for all languages, but personally I'd avoid any third party wheels.


[BUG] Unable to login when password contains certains characters

Summary
Is not possible to login into your user account in PWA if your password contains certain characters such as î·¬èº
Steps To Reproduce

Create an account where the password has any of the following characters î·¬èº
Logout
Login to the just created account

Expected result
Be able to login
Actual result
Login screen shows "Incorrect username or password, please try again."
System Information (as applicable)
Browser: Firefox & Chrome
pwa-kit version: develop
Desktop OS: Windows 10
Additional information
See the fix for PWA 2.7.1: https://github.com/SalesforceCommerceCloud/pwa-kit/issues/1243

Hi @jpuxan-osf, thanks for filing an issue on the PWA kit as well. As this bug is already being tracked in the PWA kit repo, I will close out this issue and the PWA kit team will follow up on this bug when it is resolved.


Install without an internet connection using only the iso content?

This is more of an question about the process rather than an issue with script that prepares the iso.
I tried to install High Sierra, having successfully created the iso using the script. Everything goes fine except that it appears to download everything from Apple instead of using the iso (already the product of a 6GB download). Do I have that wrong? The install time was estimated at 3+hours.
I killed everything and tried again with the network cable (virtually) unplugged. This time the installer would not start, but popped up an error stating that The Recovery Server Could Not Be Contacted.
I killed everything once more and tried again with Sierra, which works as expected and takes around 15 minutes to complete.
So, is it possible to install High Sierra without an internet connection using only the content in the iso?

I started with Mojave, after updating the script to produce an iso, but that has problems because VirtualBox lacks certain support - it hangs during the initial text part of the boot process at apfs_module_start and my initial reading indicates that virtualbox lacks afps support. So I tried to install High Sierra (unsuccessfully because I didn't want to download everything again), and then I successfully installed Sierra.
(All images were downloaded from Apple using my macBook Air which is currently running Sierra.)

It seems that Apple does some sort of 'integrity check' in High Sierra which always requires re-downloading the bulk of the installer. Not sure why, but it is what it is.
I haven't tested Mojave at all, but yeah, VirtualBox and APFS don't really work together.

Just thought I'd close this out by saying that my High Sierra ISO was 10.13.1 so I downloaded the final High Sierra 10.13.6 to see if that would install without further downloads but it still insisted on 2.5 hours of further downloads.
But the install does work, as long as you don't mark the device as being an SSD (VBoxManage storageattach $vm --nonrotational off ...) in addition to not selecting APFS. I only did the latter on my first attempt but the disk gets convereted to APFS anyway unless VirtualBox presents it as nonrotational.
For background interest, my virtual disk is a raw vmdk overlaying a raw ZFS zvol in a ssd zpool.
I did patch the script for Mojave and I was going to offer a PR but, given I cannot boot it, I can't fully test it so I am going to stick with High Sierra and wait to see if Virtualbox adds the required APFS support. I was going to try Clover but I've never used it so it would be a digression into a black hole for time...

This issue has come up again because it appears that Apple has turned off the Internet Recovery servers for macOS 10.13 and earlier. This affects any installer disk images for 10.13 not created with createinstallmedia. I encountered this when installing from disk images generated by my own disk image creation script for VMware Fusion/ESXi, and solved it by switching to createinstallmedia for 10.13 and later. So far 10.14 and 10.15 disk images still work (and still re-download their assets during installation)… for now.


Releasing the lock when the lock is determined to be acquired. Why does this error occur? IllegalMonitorStateException - Attempt to unlock read lock, not locked by current thread

RLock lock = lockService.getLock(TOPICNAME_LOCK_PREFIX + topicPrefix);
        if (lock.tryLock(5, TimeUnit.SECONDS)) {
            try {
                // Process business CODE

            } catch (Exception e) {
               throw new ServiceException(String.format("error: %s！", e));
            } finally {
                lock.unlock();
            }
        }
        // No lock obtained CODE

lockService code：
    private static RedissonClient redissonClient;
    private static synchronized void initClient(String url) {
        if (redissonClient == null) {
            try {
                URI uri = new URI(url);
                Config config = new Config();
                SingleServerConfig srvConfig = config.useSingleServer().
                setAddress(String.format("%s://%s:%s", uri.getScheme(), uri.getHost(), uri.getPort()));
                if (StringUtils.isNotBlank(uri.getUserInfo())) {
                    srvConfig.setPassword(uri.getUserInfo());
                }
                config.setLockWatchdogTimeout(10000);
                redissonClient = Redisson.create(config);
            } catch (Exception e) {
                log.error(String.format("cannot init redisson client by %s", url), e);
            }
        }
    }

    @PostConstruct
    private void init() {
        initClient(redisProperties.getUrl());
    }

    public RLock getLock(String key) {
        initClient(redisProperties.getUrl());
        return redissonClient.getLock(key);
    }

<dependency>
        <groupId>org.redisson</groupId>
        <artifactId>redisson</artifactId>
        <version>3.17.7</version>
 </dependency>

redis version 4.0
Exceptions sometimes occur：
java.lang.IllegalMonitorStateException: attempt to unlock lock, not locked by current thread by node id: ?? thread-id: ?? at org.redisson.RedissonBaseLock.lambda$unlockAsync$2(RedissonBaseLock.java:328) at ...
The business logic is that only one task is allowed in a certain range, so it needs to acquire the lock first, and other tasks are waiting. If it does not obtain the lock after waiting for 5 seconds, another set of logic will be executed.
This set of code has almost no errors, because lock.unlock() is only executed if lock.tryLock(5, TimeUnit.SECONDS) returns true.
However, for certain business peak hours, the above exceptions sometimes occur. The specific performance is that many tasks report errors: java.lang.IllegalMonitorStateException: attempt to unlock, not locked by current thread by node id: SameId thread id: DifferentThreadId.The above error reports occur in a centralized manner. Many threads release the same lock within a few seconds.
Is this caused by network? Or is there a problem with the code?

My biggest question is, since it has been determined that [lock. unlock () is only executed if lock. tryLock (5, TimeUnit. SECONDS) returns true.], why do dozens of threads still have exceptions when unlocking in a few seconds?

Check for keys eviction policy https://redis.io/docs/reference/eviction/

Fixed. Thanks for report


OpenID Connect Test

Version: 1.1.37

Describe the bug

I tested my Authorizer instance against an OpenID Connect test suite: https://openidconnect.net/
It failed on step 3: Verify the user token.

Steps To Reproduce

Fill the test on https://openidconnect.net/
Here is a gif of my test

Expected behavior

To pass the test.
Example from running the test against a Zitadel instance:

Screenshots

Desktop (please complete the following information):

OS: macOS
Browser chrome

Additional context

PS: I know i leaked my credentials but ill rotate them

@felipereyel I tried reproducing it but it worked for me

I'll try again later today to see if any of the new releases fixed it.


Fix dashboardExists monitoring installation check

Summary
Fixes #6977

Occurred changes and/or fixed issues

Replaced the check for a monitoring installation within dashboardExists. The original check was looking for a schema for monitoring.coreos.com.servicemonitor which exists regardless if monitoring is installed.
Areas or cases that should be tested

Any place where allDashboardsExists is called

Cluster explorer page
Node detail
Pod detail
Workload detail
Harverster list page
Harverster kubevirt.io.virtualmachine detail

Hey @jordojordo , so there's an issue within your branch (this one) where if you want to check POD details view you get a blocking error on the console (check screenshots). Also, it's loading the details/workload view rather than details/pods.
I believe that the problem is that this branch is not up-to-date. I think Shavin did some work around this area a few days ago. Can you rebase and check this?
Otherwise, code and testing it all LGTM 🙏
Thanks!
This branch

my master

@aalves08 I've updated the branch and tested the pod detail page, everything appears to be working as it should.


Skyline: Cleanup persistent folder before and after test runs

Helps avoid the case where a prior failure causes an echo failure in the next run because cleanup deletes left over files in the persistent folder

Yes. Feel free to add them. I am focusing on the 24 officially published
tutorials. Feeling like we need an indicator for whether a tutorial is
officially published as a lot has crept into the list that is not yet
officially published.
Though maybe that is already ending in Tutorial for officially published
and I just need to downgrade the tutorials that are not official to ending
in TutorialDraft
On Fri, Dec 6, 2024 at 8:16 AM Matt Chambers @.***>
wrote:

@.**** approved this pull request.
It's great to make it more robust to failures. There are probably more
tests that need CleanupPersistentDir() overloads added though, right?
—
Reply to this email directly, view it on GitHub
https://github.com/ProteoWizard/pwiz/pull/3266#pullrequestreview-2485305166,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACYBWUF43OQAUX2RSWQV7GL2EHEUVAVCNFSM6AAAAABTDWKQNCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDIOBVGMYDKMJWGY
.
You are receiving this because you authored the thread.Message ID:
@.***>