Go to definition don't working correctly

Environment data

VS Code version: 1.21.0
Extension version (available under the Extensions sidebar): 2018.2.1
OS and version: Linux Mint 18.3
Python version: 3.5
Type of virtual environment used (if applicable): venv
Relevant/affected Python packages and their versions:

Actual behavior
Go to definition of some used class not open file with it definition
Expected  behavior
Go to definition of some used class open file with it definition
Steps to reproduce:

File a1.py have class Foo: pass
File b1.py have

from a1 import Foo
class Bar(Foo):pass

Click "go to definition" in file b1 on Foo, must open a1 file with definition of Foo, but moving cursor to first line with import of Foo
Downgrade to 2018.1.0 solve this problem

Logs
Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)
##########Linting Output - flake8##########
##########Linting Output - flake8##########

Output from Console under the Developer Tools panel (toggle Developer Tools on under Help)
[/home/john_16/.vscode/extensions/donjayamanne.githistory-0.4.0]: Команда "git.viewFileHistory" встречается несколько раз в разделе commands.
/usr/share/code/resources/app/out/vs/workbench/workbench.main.js:257 [Extension Host] TypeDefinition null
/usr/share/code/resources/app/out/vs/workbench/workbench.main.js:257 [Extension Host] Extension "currenttodos" activated!
/usr/share/code/resources/app/out/vs/workbench/workbench.main.js:257 [Extension Host] vscode-icons is active!
/usr/share/code/resources/app/out/vs/workbench/workbench.main.js:257 [Extension Host] (node:23354) DeprecationWarning: os.tmpDir() is deprecated. Use os.tmpdir() instead.
t.log @ /usr/share/code/resources/app/out/vs/workbench/workbench.main.js:257

This reproduces for me under Python 2, 3.5 and 3.6 (all virtualenvs on Ubuntu).
Notably on importing a1 as a whole module and referencing Foo as an attribute of that, going to the definition of Foo goes directly to the class definition in a1.py:
import a1
class Bar2(a1.Foo): pass

Separately, this bug feels reminiscent of https://github.com/DonJayamanne/pythonVSCode/issues/781 and https://github.com/DonJayamanne/pythonVSCode/issues/742; perhaps a fix might be found in a similar location?

This reproduce for me on macOS python3.6.
It's only occure on my own code. If i go to the definition of a library, this seems to works as expected

I found something that may help from here

This seems to be because the extension uses goto_definitions instead of goto_assignments when calling Jedi. Calling goto_assignments instead fixes this, but changes the behavior when going to an imported function.
i.e. with the current code clicking on bar in this code
from foo import bar

bar()

will jump to bar in the foo module, but if goto_assignments is used this will jump to the from foo import bar line.

I guess, vscode-python switch from goto_definitions to goto_assignments.
I think giving a setting option to choose between goto_definitions and goto_assignments is a better solution. (I like goto_definitions)

@ocavue we actually use both as necessary.
This appears to be a semantic change between 0.10.x and 0.11.x which we upgraded to in the 2018.2.0 release.

@brettcannon you are right. I clone v0.9.0 Jedi and everything is fine. Thanks to python.jediPath setting.

@brettcannon does that mean that there's now an open issue upstream for this? (I can't immediately see one, but would be happy to create one)
The jedi changelog doesn't note any changes around the goto* api methods in 0.11.x, it would be good to understand where you think the difference is?

@PeterJCLaw I did not open an issue upstream, no. Are you up for opening one?

@brettcannon apologies for the delay on this. I've just had a look into this with the aim of understanding it better to report it upstream.
My understanding of things is as follows:

definition requests make it into completion.py, specifically the section in _process_request() for  lookup == 'definitions'
while that code hasn't changed, the behaviour of goto_assignments(follow_imports=False) has done
side-note: I can't tell why goto_assignments is called twice, once with the explicit follow_imports=False and once without. The latter appears redundant to me since the value of follow_imports is the same in both cases. (Is there some side-effect to the intervening goto_definitions call that we're making use of?)
I strongly suspect that the change in goto_assignments is a bug-fix. The previous implementation was returning a value which had followed an import, despite being asked not to do so. I can't find a direct bug-report for that in jedi, though the commits which make the changes (https://github.com/davidhalter/jedi/commit/6940900c58cbe62b74b467bd48536304cefd1ebe, https://github.com/davidhalter/jedi/commit/619acbd2ca6dfb62fc325330458cc01ee97329f2, https://github.com/davidhalter/jedi/commit/4a544c29ea57fde519971c9c3fc0f1c7fd1262bc, https://github.com/davidhalter/jedi/commit/5ff7e3dbbeba3d1f07eadd9321c4fe99d35a51b5) claim to be fixing a number of issues, including https://github.com/davidhalter/jedi/issues/956 which appears related to import following

Based on all that (plus a hunch based on the name of the argument) I tried changing the value of follow_imports in the first call (such that it's passed named as True rather than named as False). Doing so fixes this bug for me.
If you (@brettcannon) agree I'll put up a PR for that. (Are there tests for this area which I could add a test case to?)
I am slightly puzzled why we previously had follow_imports=False though as that seems undesirable, so I'm worried that there are other cases which I'm missing and that that breaks. Are there any similar cases I should check still work?

@brettcannon how large a fix would you like to make here?
I can see a couple of options: just the small fix which resolves the original report, or a larger change which simplifies the definition lookup code in _process_request to a single goto_assignments(follow_imports=True) call. I'm interested in helping fix this either way, though might need a bit more guidance on testing of the larger change (if that's the approach you want).

How large is large? I'm personally fine with a small fix, but if e.g. less than 20 lines or so for the bigger one and there is larger win for users then we will happily help you with the bigger fix.


30 sprinkler utils is not properly transitive in sprinkler binary transcoders

Created a new module jvm-bridge that can be imported with the api configuration using gradle.
closes #30

Documentation update and Changelog are missing


Prevent breadth-first attacks in login throttling

Note, I have already discussed this with Taylor to verify that he was okay with me posting this security related "issue".
I recently contracted a security firm to do a penetration test on a Laravel 5.8 app. They had concerns with how login throttling works in Laravel. Here are their findings:

Observation
One or more password validation mechanisms were designed or configured in a way that did not offer sufficient protection to prevent password guessing attacks.
Implication
An attacker may be able to discover the password of one or more user accounts, which may result in unauthorized access to the authenticated portion of the system, or the ability to perform an account takeover.
Findings
The testing team discovered that, though there were mechanisms in place which prevented target password guessing against a single account, these were insufficient to prevent breadth-first guessing attacks. After approximately 50 guesses against a single account, the server began rate-limiting attempts against the targeted account. This mechanism was not activated when many attempts were made against different accounts, allowing breadth-first attacks.
The observed behavior was presumed to be a result of elapsed time between attempts against individual accounts being long enough to avoid triggering the identified rate-limiting mechanism, though the testing team was unable to determine exactly how this functionality worked. Breadth-first guessing attacks appeared to be possible against as few as eight accounts without causing the application to begin rejecting login attempts.
Figure 6: Over 800 login attempts were made without triggering the application’s rate-limiting mechanism.

Additionally, when the rate-limiting functionality was triggered it did not function as intended. The server responded with an error noting the user was required to wait a given number of seconds before making more login attempts, though subsequent attempts within the time frame were still able to authenticate to the application, effectively only blocking the specific attempt which caused the error to trigger.
Figure 7: A login attempt, highlighted in blue, returned an error noting there had been too many attempts against an account and the account had been locked for 34 seconds, though another attempt made only a few seconds later, highlighted in red, was still able to authenticate using the correct credentials.

Recommendation
Modify the components and/or configuration of the password validation mechanism to help prevent password guessing attacks. For typical scenarios (breadth-first attacks), this requires multiple components working in concert to implement an effective solution. Limiting the rate of submissions and preventing users from choosing passwords easily guessed by attackers – particularly those that meet typical complexity requirements, such as Spring2019 – are the most effective means of preventing an attack.

The login throttling in Laravel is done on a per username (email) basis, not simply based on the user's IP address. The key is set in ThrottlesLogins@throttleKey, and is a combination of the username and IP address. What this means is that an attacker can attempt logins on different accounts without any rate limiting. They call this a "breadth-first attack".
What's maybe more concerning is that even when rate limiting has been triggered (you get a 422 with "Too many login attempts. Please try again in {x} seconds."), there is nothing stopping you from trying again with a different email address and logging in immediately if that authenticates. Even if Laravel does continue to track login attempts using a username and IP address combination, I think it would make sense to prevent subsequent login attempts until the rate limit period has been hit, regardless of what username you're using.
My immediate thought that maybe a better approach might be to simply use the IP address as the key. However, from some research I don't know if that's reliable or safe either, since it's possible to spoof an IP address. Further, if you're behind a load balancer or proxy, you have to rely on X-Forwarded-For, which is even less reliable.
Further, even if the IP address was reliable, it can be problematic for large organizations that all share the same IP address. If one person at the organization caused rate limiting, all other people there would also be forced to wait.
I don't have a solution for this yet, but wanted to post this to generate some discussion.

Is there an alternative Rate Limiting libray for PHP?

could we integrate a session based key? could help on browser users, but doesn't help with stateless situations.

I believe Sentinel handles this differently, already has the IP restrictions as well as global throttling. So if attempted through a DDoS attack it would throttle everyone connecting thus handling that. Probably needs the same handling in the framework itself.

Hmm, global throttling, that's interesting. The relevant Sentinel docs: https://cartalyst.com/manual/sentinel/2.0#throttle

My immediate thought that maybe a better approach might be to simply use the IP address as the key. However, from some research I don't know if that's reliable or safe either, since it's possible to spoof an IP address. Further, if you're behind a load balancer or proxy, you have to rely on X-Forwarded-For, which is even less reliable.

Well we already use the IP + username, so using just the IP as an "overaraching" rate limiter doesnt seem to be any less reliable?

Further, even if the IP address was reliable, it can be problematic for large organizations that all share the same IP address. If one person at the organization caused rate limiting, all other people there would also be forced to wait.

Having a higher "IP" rate limiter than the local "IP + username" might solve this.
i.e. 5 attempts for "IP + username", but 25 attempts (configurable) for IP only would probably stop the breadth-first attack.
And then if a single user at large organisation forgets their password, they get locked out after 5 attempts, but the rest of the organisation (on the same IP) does not (because global limiter is not affected).

Stacking the throttles would be my approach, using separate keys based on the usernames and IP addresses.

Further, even if the IP address was reliable, it can be problematic for large organizations that all share the same IP address. If one person at the organization caused rate limiting, all other people there would also be forced to wait.

There's a chance of disruption for genuine users here, but the chances are fairly small I think. You only have to throttle enough to stop someone from brute forcing passwords, which is less likely to affect someone typing their password incorrectly a few times. That said, if you have that many on one IP, might be worth whitelisting it somehow.
Tiering the throttles based on the same unique key gives you a "burst" effect. The system can handle a burst of authentication requests (e.g. when everyone logs on at 9am), but the "wider" throttles take care of any prolonged attacks that work around the "narrower" throttles.
Numbers are just examples:
<ip>|1 200 attempts per 5 minutes
<ip>|2 1000 attempts per hour
<ip>|3 5000 attempts per 24 hours
<username>|1 10 attempts per 5 minutes
<username>|2 20 attempts per hour
<username>|3 50 attempts per 24 hours
<username>|4 150 attempts per month
On a side note, it would be pretty awesome for the "default" settings etc of a framework to be battle hardened against a pen test like this :+1:
Caveat emptor: I am not a security researcher

@davedevelopment Dig it. Would you add a global tier, in case of DDoS attacks or IP spoofing?

@davedevelopment Dig it. Would you add a global tier, in case of DDoS attacks or IP spoofing?

I'm not sure really, having read the Sentry docs, my first reaction would be that you're enabling a DDoS. Fire up enough bots running enough failed login attempts to meet the throttle and then nobody can log in. My gut feeling is that if you think there is a risk there, it should be handled elsewhere in your infrastructure.

Yeah, I see what you mean. This probably depends on the app. I'd probably rather have no users be able to login than for an attacker to be able to guess a username/password combo (as unlikely as that realistically is).

|1 10 attempts per 5 minutes

Would/should this be <username+ip> though? Because otherwise anyone can lock someone's account?

Would/should this be <username+ip> though? Because otherwise anyone can lock someone's account?

Personally, I'd say no, but I guess it always depends. If someone is making a targetted effort to guess a particular person's password, I'd rather the actual person gets locked out of their account than increase the number of chances the attacker gets.

This probably should all be configurable to allow everyone different levels of protection based on their persoanl preferences, otherwise everyones's going to argue they want it a different way.

If someone is making a targetted effort to guess a particular person's password, I'd rather the actual person gets locked out of their account than increase the number of chances the attacker gets.

But this makes the site subject to a different attack, where you can lock people out of accounts just by spamming the login page using known logins. The current throttle system avoids this exact issue (by using username + ip), so we wouldnt want to move away from that.

Probably the simplest solution is to just add the built in ThrottleRequests middleware to the login route to handle breadth-first attacks.
By default, for an unauthenticated request, it uses <domain>|<ip>.
For a large DDOS attack, I would imagine you'd need a more robust firewall solution in any case.

@laurencei is it possible to keep a list of trusted IPs from user login history, to alleviate the problem ?
The server says : "you have used this IP before and you are using it again so no problem... you are logged in."

But what if we add a second throttling on it that checks only on the IP and has a higher limit and also make it configurable inside the auth config file for both?
Maybe firing an event when the IP limit is reached so that you can hook into for notifications as they like.
We are going to find a solution for DDOS attacks but at least with this solution you can block the "breadth-first attack" in a way.

What are the downsides of a session based key? Would that use too much server resources?

So does this mean that throttling for login is useless at the moment? Even if you're locked out, you'll still be logged in if you send the correct password?

@reinink It's not a complete solution but have you considered triggering a good captcha after x attempts per ip, user (or both) as part of the throttling mechanism? This effectively throttles an automated attack and is the kind of check you can apply this on on a per user, per IP or global basis with only minimal inconvenience for genuine users. Any attackers who wanted to proceed once the captcha in place would face a significantly higher cost per guress depending on the quality of the mechanism used (think google recaptcha, which even as a human I frequently fail.)
If you're in a stateless scenario here you should probably be using a longer api key that would be much harder to brute force anyway.

What if database will be used for rate limiting (as an out-of-the box option)?
|id|user_id|attempts|created_at|updated_at|

Workflow could be like that:

user makes invalid login attempt - one INSERT (1 query)

|id|user_id|attempts|         created_at|         updated_at|
| 1|      1|       1|2019-05-24 17:03:00|2019-05-24 17:03:00|

user makes second invalid login attempt

SELECT attempts / (TIMESTAMPDIFF(UNIX_TIMESTAMP() - created_at)) FROM throttles WHERE user_id = 1

, compare it with throttle rate from config/etc and make an increment if needed. (1 or 2 queries)

user makes successful login attempt (1 query)

DELETE FROM throttles WHERE user_id = 1

P. S. Or Redis/MemCached/...

Say you get a DDoS, and you insert into your database? Seems like a really bad idea in that sense as you are now pushing the attack at your database. As some other people have suggest it may be better to handle this at a more hardware/firewall layer before it hits the application.

@donnysim

So does this mean that throttling for login is useless at the moment? Even if you're locked out, you'll still be logged in if you send the correct password? Getting too many attempts error is jus an another "Incorrect password" error?

Thats what I read at first also, but as far as I can tell you can still only try different accounts. You cannot try with the same username (/email) within the locked period.

I would vote to escalate to a pure IP block after more unsuccessful login attempts, but it seems like that adding reCAPTCHA to the IP requests rather than throttling is the best solution to stop these kind of attacks.
The block could be on a higher number of failed attempts, and the time to release the lock should be higher too. If a whole net gets throttled because someone decided to brute Force is way into the application, nothing is lost since is a problem of the user, not he application.

Any news on this? Seems it should be priority. It seems odd its only locking out a IP to a specified username/email and not just IP itself. Botnets for instance. They can hit a username/email until its locked and then just move on to a new username/email since the IP is still good for use using a different username/email. For sites also using things like a Failed Login system that emails a user and logs in the DB failed login attempts your now also getting your DB hit a lot and emails too.
reCAPTCHA is not a good solution IMO when it comes to BotNets trying to breadth-first attacks a login page.

reCAPTCHA is not a good solution IMO when it comes to BotNets trying to breadth-first attacks a login page.

v2 or v3?

Both have failed for me.

Both work wonders for me. Check your configs.

Additionally, from an IPv6 source address, you can freely pick from 2^64 temporary addresses. Meaning a particular IP-address block, as currently implemented, is easy to circumvent.

I came across the same situation albeit that my PEN testers did not complain about breadth-first... regardless, I needed a solution, so I ended up doing:

New ThrottleRequests middleware that acts upon response status code 401
Takes (separate) request signature and username hashes
Stores the hashes in a DB table using a sliding window, so there's always at most the amount of maximum hits in the table per hash key
Checks against config whether or not there were too many hits. If so, calculates the time in seconds between the oldest and the newest.
If there are more hits than allowed and if the period is shorter or equal to the period allowed (configured) the IP address on the request is banned.
Banning results in Log::critical and an email being sent (if mail and mailable for this solution are configured)

This is probably "quick and dirty" (when looking for a generic approach) and might need some more config possibilities (DB / Cache / Redis / memory / whatnot drivers; needs testing for performance; needs verification as to whether this can be applied to any route, rather than just the login route(s)).
If anybody wants to discuss this further, please contact me on twitter.

I think the way Laravel does it at the moment does make sense, that is to throttle by ip+username. However in addition to this to prevent "breadth-first" maybe there should be a global throttle limit on the authentication route. It would be good to have Laravel set a sane default out the box.
In LoginController.php just add a global throttle limit in the construct method:
    /**
     * Create a new controller instance.
     *
     * @return void
     */
    public function __construct()
    {
        $this->middleware('guest')->except('logout');
        $this->middleware('throttle:20,60')->except('logout'); // global login limiter 20 login attempts every hr
    }

I agree @garygreen, a global throttle would be a simple way to mostly mitigate this risk. The rules would have to be pretty lax though, since you'd essentially be locking out all users. For example, instead of locking out all users for one hour after 20 failed login attempts, I'd be more inclined to lock out all users for 1 minute after 50 failed login attempts.
Going off what Cartalyst does, there could be three layers to this:

Global
IP
User

It's helpful to actually think of these in the opposite order:

User throttling: Most aggressive, since it only affects one account (email).
IP throttling: A little less aggressive, since it only affects the users on a single IP address.
Global throttling: Pretty lax, since it affects all accounts. This is really a catch-all, just incase someone is spoofing IP addresses, or a DDoS attack is occurring.

This is basically the same staggered approach @davedevelopment is suggesting, with the addition of a global throttle.

Those options sound sensible @reinink - I did send a PR to Laravel some time ago for changing the throttler and suggesting ways for it to be more customisable in terms of how it throttles (essentially just need to control the throttle signature - by default, Laravel restricts by user id OR ip.
You may find it interesting some of the ideas in the PR: most relevent comment

This issue is still open, so I'd figure I throw in an idea.
Rate Limiting Authentication Attempts
The whole idea behind rate limiting is denying service (Denial of Service), given too many requests have been made within a certain amount of time. Unfortunately we have conflicting interests. We want to prevent malicious third-parties from gaining access to accounts, but we also don't want to deny service either.
Source:

It is difficult to act against adversary who tries a few “most common passwords” from many different sources against every account on the system, but we can focus especially on the “multiple source against single account” and “single source” threats.

By IP
Example: 24 invalid authentication attempts within a day are permitted to each IP.
Another example: 4 invalid authentication attempts within 4 hours are permitted to each IP.

There are a lot of proxies available to everyone, meaning distributed attacks are possible.
Because of the previous point authentic users could be also be attempting to authenticate through proxies.
Additionally this isn't sufficient for mitigating targeted attacks.
Because of the first, and previous point: rate limiting by IP alone isn't sufficient.

Once the IP has been locked, the IP can't be used to attempt to authenticate any accounts.
For a Specific Account
Example: Each account is allowed 24 invalid authentication attempts within a day.
Another example: Each account is allowed 4 invalid authentication attempts within 4 hours.
If the account is locked, it is protected against both targeted, and distributed attacks.
Globally
idea 1: round_to_discrete(invalid authentication attempts permitted per account * factor * number of accounts) is the total allowed amount of invalid AND valid authentication attempts per day. If the total has been reached, all accounts are locked. The factor can be adjusted, I'd say .125(an 8th) is good (probably not best to put it above .5). The lower the factor, the sooner all of the accounts are locked.
Example: 24 invalid authentication attempts permitted per account, 256,783 accounts registered, with a factor of .125 = 770,349 total permitted authentication attempts. This will give 3 attempts for all of the accounts.
idea 2: We could also declare a stricter rule, that about a 4th the number of accounts is the total number of invalid AND valid authentication attempts per day.
Example: 256,783 accounts, and a factor of .25 = 64,196 total authentication attempts.
Preventing Denial of Service
When an IP or account is locked, we(the application) have denied our authentication services. We do not want to deny service to our authentic users. We can send a temporary(an hour, or a few is good), and unpredictable(using a CSPRNG) authentication page to the user's email, if the account is locked, or the IP is locked. NOT a link that magically authenticates them.
So when clients try to login to a locked account, or they are using a locked IP don't attempt authentication. Simply ask for confirmation if they'd like a temporary login link sent to their email. These links are specific to an account, so users shouldn't need to provide an identifier(email, username, etc), or go through multiple page loads if there is multiple factors of authentication enabled on their account. They should only be able to request a new one every 15 or 30 minutes. Previous links should be deleted/invalid.
If accounts have been locked globally, make sure to tell users all accounts have been locked because too many authentication attempts have been made that day. And that it's in place to mitigate adversaries from trying to guess passwords.
The link MUST be:

Unpredictable
Ephemeral
Invalid after invalid authentication attempts permitted per account

The link SHOULD be:

Kept secret
Invalid once, or a couple of times after a successful login

Although the link is confidential, the account is not compromised if adversaries obtain it.

@lynn-stephenson So basically, if the IP is throttled, we send a login link with a CSPRNG that bypasses the throttle and allows to log in.

@lynn-stephenson So basically, if the IP is throttled, we send a login link with a CSPRNG that bypasses the throttle and allows to log in.

If the IP, or account is locked(throttled), then yes. A link is sent to the email. Then the user clicks on the link, and provides their credentials.
Because there is a way to bypass throttling, I'd suggest making it strict.

If the IP, or account is locked(throttled), then yes. A link is sent to the email. Then the user clicks on the link, and provides their credentials.
Because there is a way to bypass throttling, I'd suggest making it strict.

Okay, but now the implementation becomes not-so-nicer. We would need to catch the User once is been retrieved (but not Validated) and check if the request is throttled or not. Then it would need to stop the authentication and redirect/show "Check your email to Login", or continue if the CSPRNG is present and correct.
Should the controller be responsible of throttling the request, or the guard itself? If it's the controller, then the Session Guard should also have access to a throttle information of the Request itself.
In any case, for that to work, we would need to add a "Retrieved" event to the Session Guard, that would fire when the User is successfully retrieved from the UserProvider. With that information we can check if the user exists, since we need only to send him an email (if it's not, we fake it).
I don't know if @taylorotwell will be too keen to have another event in the Session Guard, but from my perspective, having that event could enable more advanced tinkering with the Guard itself.

Should the controller be responsible of throttling the request, or the guard itself? If it's the controller, then the Session Guard should also have access to a throttle information of the Request itself. How it would know when to send the email?

I don't feel like this belongs in the Session Guard, as this doesn't have anything to do with sessions, and shouldn't be tied to the sessions. This is strictly for authentication rate limiting purposes. The rate limiting is per-IP, and per-user; not per-session. So I believe this should be a controller approach.
Adversaries could simply delete the session that's stored in a HTTP cookie, and have a new session. Easy to bypass session-based rate limiting. We don't want that.

Analogy: The login page is the front door. When the doorman decides to deny service because you attempted to enter too many times, or the list name had already been attempted too many times, he can send mail to the list name's house with a key that permits the doorman service for a specific list name, regardless of who you are, as long as you have the key. Once you've gone in through the front door successfully, then you've got a session.
This is essentially how it works, to prevent denial of service for authentic users.

我们可以集成基于会话的密钥吗？可能对浏览器用户有所帮助，但对无状态情况没有帮助。

This issue is still open, so I'd figure I throw in an idea.
Rate Limiting Authentication Attempts
The whole idea behind rate limiting is denying service (Denial of Service), given too many requests have been made within a certain amount of time. Unfortunately we have conflicting interests. We want to prevent malicious third-parties from gaining access to accounts, but we also don't want to deny service either.
Source:

It is difficult to act against adversary who tries a few “most common passwords” from many different sources against every account on the system, but we can focus especially on the “multiple source against single account” and “single source” threats.

By IP
Example: 24 invalid authentication attempts within a day are permitted to each IP.
Another example: 4 invalid authentication attempts within 4 hours are permitted to each IP.

There are a lot of proxies available to everyone, meaning distributed attacks are possible.
Because of the previous point authentic users could be also be attempting to authenticate through proxies.
Additionally this isn't sufficient for mitigating targeted attacks.
Because of the first, and previous point: rate limiting by IP alone isn't sufficient.

Once the IP has been locked, the IP can't be used to attempt to authenticate any accounts.
For a Specific Account
Example: Each account is allowed 24 invalid authentication attempts within a day.
Another example: Each account is allowed 4 invalid authentication attempts within 4 hours.
If the account is locked, it is protected against both targeted, and distributed attacks.
Globally
idea 1: round_to_discrete(invalid authentication attempts permitted per account * factor * number of accounts) is the total allowed amount of invalid AND valid authentication attempts per day. If the total has been reached, all accounts are locked. The factor can be adjusted, I'd say .125(an 8th) is good (probably not best to put it above .5). The lower the factor, the sooner all of the accounts are locked.
Example: 24 invalid authentication attempts permitted per account, 256,783 accounts registered, with a factor of .125 = 770,349 total permitted authentication attempts. This will give 3 attempts for all of the accounts.
idea 2: We could also declare a stricter rule, that about a 4th the number of accounts is the total number of invalid AND valid authentication attempts per day.
Example: 256,783 accounts, and a factor of .25 = 64,196 total authentication attempts.
Preventing Denial of Service
When an IP or account is locked, we(the application) have denied our authentication services. We do not want to deny service to our authentic users. We can send a temporary(an hour, or a few is good), and unpredictable(using a CSPRNG) authentication page to the user's email, if the account is locked, or the IP is locked. NOT a link that magically authenticates them.
So when clients try to login to a locked account, or they are using a locked IP don't attempt authentication. Simply ask for confirmation if they'd like a temporary login link sent to their email. These links are specific to an account, so users shouldn't need to provide an identifier(email, username, etc), or go through multiple page loads if there is multiple factors of authentication enabled on their account. They should only be able to request a new one every 15 or 30 minutes. Previous links should be deleted/invalid.
If accounts have been locked globally, make sure to tell users all accounts have been locked because too many authentication attempts have been made that day. And that it's in place to mitigate adversaries from trying to guess passwords.
The link MUST be:

Unpredictable
Ephemeral
Invalid after invalid authentication attempts permitted per account

The link SHOULD be:

Kept secret
Invalid once, or a couple of times after a successful login

Although the link is confidential, the account is not compromised if adversaries obtain it.
Public link:
https://site.com/login

Ephemeral, unpredictable, and confidential login form that bypasses locked account/IP link:
https://site.com/login/1159e55cb3093925d4716bac2f01b2c4dd2c88a0e56c484ec48c0767693c36c1

good

good

We could tackle this with a throttler Middleware on the POST login route.
This Middleware should register a listener at run time to the Failed auth event in to check if the authentication fails. The data would be used to throttle the account, or the IP, depending on the case.
If the IP has only one throttled account, only that account will receive a login email. If the IP has more than one throttled account, then all accounts will receive a login email.
The throttler listener will check if the user exists in the user provider (we would need an auth event called "Retrieved" too) but would interrupt the attempt and throw a a response telling an email has been dispatched. If the user doesn't exists, the same response would be sent but bogus.

Maybe disable login by default unless a cookie is present containing global attempt count.

I feel like you could simplify this by setting a cache key for the number of login attempts globally within X minutes. If more than X number of login attempts are made (regardless of credentials or IP), display and require a CAPTCHA for every login attempt.
That way:

You don't lock out legitimate users
You don't require CAPTCHA for every login attempt all the time
You don't need to worry if a DDOS attempt uses thousands of distinct IPs

I feel like you could simplify this by setting a cache key for the number of login attempts globally within X minutes. If more than X number of login attempts are made (regardless of credentials or IP), display and require a CAPTCHA for every login attempt.
That way:

You don't lock out legitimate users
You don't require CAPTCHA for every login attempt all the time
You don't need to worry if a DDOS attempt uses thousands of distinct IPs

That means tackling this with a package, which you can always do. The idea of this thread is to do something relatively simple and ootb inside Laravel.

I have used this package with success in replacing the native Auth Throttle trait:
https://github.com/GrahamCampbell/Laravel-Throttle

Closing as more flexible rate limiting is coming with: https://github.com/laravel/framework/pull/32726

Thanks so much @taylorotwell! Awesome work! 👏


pg_net: 0.8.0 -> 0.11.0

Update pg_net to 0.11.0
Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

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

@NixOS/nixpkgs-merge-bot merge

@NixOS/nixpkgs-merge-bot merge

I don't think you can reasonably expect to be able to use this command, for which you need to be a maintainer already, while adding yourself as one in the same PR. Independent of whether that's already in by-name or not.

Thanks for that info. It's been some time since I have put through PR into nixpkgs, and it wasn't clear from contributing docs what various permissions are needed for these actions. But that makes sense and thank you for the clarification.


Import issue running bootstrap.py from Spyder console

Hi,
I've recently forked Spyder and would like to make some mods locally etc. I've tried running bootstrap.py from Spyder in a console but I run into import issues (I've tried both current and dedicated interpreters). In particular, the Spyder console fails to load the development version of spyderlib even after including the dev version's path in os.path (as bootstrap.py does) and changing the working directory to the spyderlib parent directory.
However, there is no issue when the script is run outside Spyder, i.e. /usr/bin/python -u -i /home/paul/github/spyder/bootstrap.py runs from the command line & Spyder's external terminal.
Any idea what's going on here? I know that Spyder uses an external shell widget to setup consoles/interpreters, which may be affecting things.
Thanks,
Paul.
Error:
Executing Spyder from source checkout
Traceback (most recent call last):
  File "/home/paul/github/spyder/bootstrap.py", line 103, in <module>
    from spyderlib.utils.vcs import get_git_revision
ImportError: cannot import name get_git_revision
>>>

Note: that get_git_revision exists in my development version of spyderlib but not my installed version.

Please use a regular (operating system) terminal to run bootstrap.py. That's how all core developers run Spyder from the git repo.
We don't have time, nor we are interested, in making bootstrap.py work inside Spyder. I hope you understand.


Qubino flush shutter DC in Homebridge

This might be related to bug #28.
I have a "Qubino flush shutter DC" (http://qubino.com/products/flush-shutter-dc/) that doesn't get recognised in homekit apps. It works fine in the zway web interface and app.
The hardware I am using is:

Raspberry Pi 3
Raspberry PI GPIO module (based on ZM5202)
Qubino flush shutter DC

Software currently running is:

Z-Way Server v2.2.2
Homebridge
homebridge-zway 0.5.0-alpha2

I get the warning that there is only a "informationservice" registered and no devices. See the log below.
What i did try was to try to separate the different controllers in the Z-Way server. The Qubino has 4 "devices" registered there: two power-measurers, one continuous controller and one switch. When i separate the switch with "Homebridge.Accessory.Id:value" I can control simple up and down, however it registers as always on (fully up).
I will try downgrading the server as suggested in #28.
The log:
[5/4/2016, 5:25:55 AM] Initializing ZWayServer platform...
ZWayServer Fetching Z-Way devices... +0ms
[5/4/2016, 5:25:55 AM] Loading 0 accessories...
ZWayServer Authenticating... +162ms
ZWayServer Authenticated. Resubmitting original request... +79ms
ZWayServer Got typeKey text for vdev InfoWidget_5_Int +43ms
ZWayServer { deviceType: 'text', probeTitle: undefined, probeType: '' } +1ms
ZWayServer Got typeKey battery.Battery for vdev BatteryPolling_7 +80ms
ZWayServer { deviceType: 'battery', probeTitle: 'Battery', probeType: '' } +0ms
ZWayServer Got typeKey switchBinary for vdev ZWayVDev_zway_2-0-37 +3ms
ZWayServer { deviceType: 'switchBinary', probeTitle: undefined, probeType: '' } +1ms
ZWayServer Got typeKey sensorMultilevel.meterElectric_kilowatt_per_hour for vdev ZWayVDev_zway_2-0-50-0 +2ms
ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Electric', probeType: 'meterElectric_kilowatt_per_hour' } +0ms
ZWayServer Got typeKey sensorMultilevel.meterElectric_watt for vdev ZWayVDev_zway_2-0-50-2 +2ms
ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Electric', probeType: 'meterElectric_watt' } +0ms
ZWayServer Got typeKey switchBinary for vdev ZWayVDev_zway_3-0-37 +1ms
ZWayServer { deviceType: 'switchBinary', probeTitle: undefined, probeType: '' } +0ms
ZWayServer Got typeKey switchMultilevel.motor for vdev ZWayVDev_zway_3-0-38 +1ms
ZWayServer { deviceType: 'switchMultilevel', probeTitle: undefined, probeType: 'motor' } +0ms
ZWayServer Got typeKey sensorMultilevel.meterElectric_kilowatt_per_hour for vdev ZWayVDev_zway_3-0-50-0 +3ms
ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Electric', probeType: 'meterElectric_kilowatt_per_hour' } +0ms
ZWayServer Got typeKey sensorMultilevel.meterElectric_watt for vdev ZWayVDev_zway_3-0-50-2 +1ms
ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Electric', probeType: 'meterElectric_watt' } +0ms
ZWayServer Got grouped device InfoWidget_5_Int consisting of devices: +1ms
ZWayServer InfoWidget_5_Int - text +0ms
ZWayServer WARN: Didn't find suitable device class! +1ms
ZWayServer Got grouped device BatteryPolling_7 consisting of devices: +0ms
ZWayServer BatteryPolling_7 - battery.Battery +0ms
ZWayServer WARN: Didn't find suitable device class! +0ms
ZWayServer Got grouped device ZWayVDev_2-0 consisting of devices: +0ms
ZWayServer ZWayVDev_zway_2-0-37 - switchBinary +0ms
ZWayServer ZWayVDev_zway_2-0-50-0 - sensorMultilevel.Electric +0ms
ZWayServer ZWayVDev_zway_2-0-50-2 - sensorMultilevel.Electric +0ms
ZWayServer Got grouped device ZWayVDev_3-0 consisting of devices: +1ms
ZWayServer ZWayVDev_zway_3-0-37 - switchBinary +0ms
ZWayServer ZWayVDev_zway_3-0-38 - switchMultilevel +0ms
ZWayServer ZWayVDev_zway_3-0-50-0 - sensorMultilevel.Electric +1ms
ZWayServer ZWayVDev_zway_3-0-50-2 - sensorMultilevel.Electric +0ms
[5/4/2016, 5:25:55 AM] Initializing platform accessory 'L��slampa sovrum'...
ZWayServer Got typeKey switchBinary for vdev ZWayVDev_zway_2-0-37 +17ms
ZWayServer { deviceType: 'switchBinary', probeTitle: undefined, probeType: '' } +0ms
ZWayServer Got typeKey switchBinary for vdev ZWayVDev_zway_2-0-37 +40ms
ZWayServer { deviceType: 'switchBinary', probeTitle: undefined, probeType: '' } +1ms
ZWayServer Got typeKey sensorMultilevel.meterElectric_watt for vdev ZWayVDev_zway_2-0-50-2 +3ms
ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Electric', probeType: 'meterElectric_watt' } +0ms
ZWayServer Got typeKey sensorMultilevel.meterElectric_watt for vdev ZWayVDev_zway_2-0-50-2 +4ms
ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Electric', probeType: 'meterElectric_watt' } +0ms
ZWayServer Got typeKey switchBinary for vdev ZWayVDev_zway_2-0-37 +2ms
ZWayServer { deviceType: 'switchBinary', probeTitle: undefined, probeType: '' } +1ms
ZWayServer Got typeKey switchBinary for vdev ZWayVDev_zway_2-0-37 +1ms
ZWayServer { deviceType: 'switchBinary', probeTitle: undefined, probeType: '' } +1ms
ZWayServer Got typeKey sensorMultilevel.meterElectric_kilowatt_per_hour for vdev ZWayVDev_zway_2-0-50-0 +0ms
ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Electric', probeType: 'meterElectric_kilowatt_per_hour' } +1ms
ZWayServer Got typeKey sensorMultilevel.meterElectric_watt for vdev ZWayVDev_zway_2-0-50-2 +0ms
ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Electric', probeType: 'meterElectric_watt' } +0ms
ZWayServer Got typeKey sensorMultilevel.meterElectric_watt for vdev ZWayVDev_zway_2-0-50-2 +7ms
ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Electric', probeType: 'meterElectric_watt' } +0ms
ZWayServer Got typeKey sensorMultilevel.meterElectric_watt for vdev ZWayVDev_zway_2-0-50-2 +5ms
ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Electric', probeType: 'meterElectric_watt' } +1ms
ZWayServer Got typeKey switchBinary for vdev ZWayVDev_zway_2-0-37 +0ms
ZWayServer { deviceType: 'switchBinary', probeTitle: undefined, probeType: '' } +1ms
ZWayServer Got typeKey sensorMultilevel.meterElectric_kilowatt_per_hour for vdev ZWayVDev_zway_2-0-50-0 +0ms
ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Electric', probeType: 'meterElectric_kilowatt_per_hour' } +0ms
ZWayServer Loaded services for L��slampa sovrum +5ms
[5/4/2016, 5:25:55 AM] Initializing platform accessory 'Rullgardiner sovrum'...
ZWayServer Got typeKey switchMultilevel.motor for vdev ZWayVDev_zway_3-0-38 +16ms
ZWayServer { deviceType: 'switchMultilevel', probeTitle: undefined, probeType: 'motor' } +1ms
ZWayServer WARN: Only the InformationService was successfully configured for ZWayVDev_zway_3-0-38! No device services available! +1ms

It is related to issue #15.

And likely #27 , since you're running Z-Way 2.2.2 . They changed all the probeType values in the API, it seems. 😠

Fixed in c074aabaf4f50019d2545b6bad4eda82d846ddad.


[ZEPPELIN-5867][JDBC] Exclude hbase-server from hive-jdbc

What is this PR for?
This PR proposes to exclude hbase-server from hive-jdbc, because hive-jdbc does not require that, and the transitive deps of hbase-server cause issue on resolving project in IDEA

What type of PR is it?
Bug Fix
What is the Jira issue?
https://issues.apache.org/jira/browse/ZEPPELIN-5867
How should this be tested?
Existing CI.
Screenshots (if appropriate)

Questions:

Does the license files need to update? No.
Is there breaking changes for older versions? No.
Does this needs documentation? No.

kindly ping @huage1994

BTW, there are still some places to have this issue. Could you please check it kindly?

@jongyoul I don't see other obvious errors/warnings after this fix, I'm fine to send PR when encountering new errors.


Update conda

Tool name
conda
Tool license
3-Clause BSD License
Add or update?

[ ] Add
[X] Update

Desired version
v22.11.1 (or latests if another stable release is made)
Approximate size
No response
Brief description of tool
Conda has recently added some significant speedups which can be combined with a dependency installed at runtime to get an order of magnitude faster package installation. (See #6785 for a few numbers.)
As conda is already installed on the runners, and as it is best practice to update it before using it to minimising the chances of it failing to install a package, it makes sense to run the latest stable version. The current runners use 4.12 (from March 2022), which is fairly old. Inline with the preinstallation policy of Latest Technology it makes sense to update it.
URL for tool's homepage
https://docs.conda.io/en/latest/
Provide a basic test case to validate the tool's functionality.
conda --version

Platforms where you need the tool

[ ] Azure DevOps
[X] GitHub Actions

Runner images where you need the tool

[ ] Ubuntu 18.04
[X] Ubuntu 20.04
[X] Ubuntu 22.04
[ ] macOS 11
[ ] macOS 12
[ ] Windows Server 2019
[ ] Windows Server 2022

Can this tool be installed during the build?
# Update conda
conda update -q conda

Tool installation time in runtime
~20 seconds.
Are you willing to submit a PR?
Yes

Hello! We are installing the latest available release from https://repo.anaconda.com/miniconda/ i.e running the Miniconda3-latest-Linux-x86_64.sh script, which downloads the latest release. So it will be updated as soon as miniconda's developers make their new latest release, we do not install non-release changes in this specific case.


add Jim Green to contributors

Signed-off-by: Jim Green<EMAIL_ADDRESS>

Jim Green to contributors


C#: reverse Vector2.AngleToPoint

Fixes #70499 ; Reverses subtraction to make C# AngleToPoint match GDScript's angle_to_point
C# glue also has the function for Vector2i (GDScript appears to have no equivalent), which I gave the same treatment
Building engine and running the example project from #70499 should output 2 zeroes (also tested Vector2i so 3)

Thanks!


DataTriggerBehavior does not work with all numeric types

I think that DataTriggerBehavior only works with int and double for numeric data. I tested with short, long, float, decimal and it does not work as expected. I used the following code:
public class SampleViewModel
{
  decimal Number { get; set; }
}

public SampleView()
{
  this.InitializeComponent();
  Loaded += SampleView_Loaded;
}

private void SampleView_Loaded(object sender, RoutedEventArgs e)
{
  DataContext = new SampleViewModel { Number = 0 };
}

<TextBlock Text="The test" HorizontalAlignment="Center" VerticalAlignment="Center">
  <Interactivity:Interaction.Behaviors>
    <Core:DataTriggerBehavior Binding="{Binding Number}" ComparisonCondition="GreaterThan" Value="-1">
      <Core:ChangePropertyAction PropertyName="Visibility" Value="Collapsed"/>
    </Core:DataTriggerBehavior>
  </Interactivity:Interaction.Behaviors>
</TextBlock>

Thanks for reporting. I can confirm the issue and I'm looking into a fix


Exception Handling

Currently engine reports exceptions in very weird and uninformative manner, making debugging a huge pain.
Review exception handling and console reporting practices to report true stack of error and meaningful messages from different parts of engine.
This is a blocker for some users to debug and submit errors to github issues, as well as contribute with errors. As open source project we should be open about the way it fails throwing exceptions, that luxury many other engines don't have.

Fixed by new resource loader.


Notice codebase and issue migration

Since we've moved codebase and issue(in progress), it's better be noticed in README.md
Ready to merge.

:+1:  let's merge!


Removed Arcadia freenode channel, added Gitter

As no one is around any more, and the topic is not set on the channel, probably best to send people straight to Gitter.

It's a shame, since I'd much prefer to be in freenode while chatting about Arcadia.

If people are not around to answer questions, every newcomer will think this project is dead.
They ask something... silence and tumbleweed ...they quit and never come back.
So you either get more people to stay on that channel, or keeping it around in the docs is a liability.


feat(accordion): add multiple sizes (#2022)

Hello there,
I saw the open issue and thought I'd make a contribution.
It took me a while to realise, but the latest @carbon/styles should have the necessary styles (specifically, just the sm and lg variants) to support the changes to add the size variations to the accordion component.
As an aside, I checked out the next branch out of curiosity and it looks like the story for the accordion doesn't have a knob for varying the size. There's been some file movement which appears to undo the knob added previously. Not sure if this is intentional.
Changelog
New

Adds size variations for the accordion component

Changed

N/A

Removed

N/A

Closes IBM/carbon-components-angular#2022

Thanks for contirbuting @miqh! Could you please follow these instructions & sign off on the commit:
To add your Signed-off-by line to every commit in this branch:

Ensure you have a local copy of your branch by checking out the pull request locally via command line.
In your local branch, run: git rebase HEAD~1 --signoff
Force push your changes to overwrite the branch: git push --force-with-lease origin feat/accordion-sizes

@Akshat55, no problem.
The amended commit with the sign-off should be there now.


Fix SBOM image signing and update image siganture verification docs

Fix CI build PR updates image digest output which was causing the Sign SBOM Image step introduced in 343e9f94c6eca025307cc5219638102c57c184c2 to fail.
Update cosign verify command flags used to verify cosign claims
and signing certificates on the Tetragon images

@sandipanpanda looks like we're still hitting the same issue :(

Ah you're right of course. Let me try it on an internal branch.

@sandipanpanda no dice https://github.com/cilium/tetragon/actions/runs/3886939668/jobs/6632626500#step:18:21

After offline discussion with @aanm, it seems that the PR is expected to fail. So let's merge it!


Could NOT find LibNETCONF2: Found unsuitable version "3.1.6"

Hi,
libnetconf2 is installed but getitng as not found

Yes, you have an old version of libnetconf2 installed so you need to update it. You can always find the latest versions in the devel branches of the respective projects.

thanks for reply @michalvasko
I checked out to devel branch but now I am getting as libpam not found

And why have you not solved the problem yourself by installing libpam but are pasting the output here? Yes, there is a new dependency but that really should not be a problem.


Drive default doc url via first doc archive (again)

Tested locally by pulling a prod copy after all the doc re-builds were done and pointing the S3 url at the prod bucket.
All doc links are presents as expected and I've manually confirmed the vast majority of them.
One package loses the doc link, and that's ParseSwift, because its using macos-xcodebuild for its doc building platform, which we don't support yet. Not sure why they've made the shift (I'd opened a PR to change it back IIRC). I think we could allow doc creation in that configuration but I hesitate to do that until we've had a discussion with the doc WG (or decided ourselves) on how multi-platform docs are best handled.

Back to draft - I want to test this from a local instance running a prod copy and pointing at the prod bucket first.

Query Performance Test is consistently recording an out of bounds maximum of 19340 (expected: 15000). There are obviously no changes in the PR that would cause this.
A run on current main shows that this is already an issue on main.
Previous runs were successful, so this is due to data changes in staging. The failing test is QueryPerformanceTests.test_Search_refresh and it's likely related to the data changes in doc_archives.
I'll take a look into this separately.


Added tests for index reducer

Coverage remained the same at 93.939% when pulling 78e801852a004dfdc1c55f67bcffc00e8cf5abee on reducer into c019761cd30f244721dbb3535e5756af013beb54 on master.


Fix date specific test

2014 doesn't appear in the select list once the date rolls around to 2020.

I think we're just old


ChartTLS: TLS with self-signed for accessing Hedera Mirror Node Explorer

:tada: This issue has been resolved in version 0.15.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Include event ID in findSimilarRegion_() check

Include event ID in findSimilarRegion_() check so that events with same presentationTime and duration but different ID are treated as separate events.
Closes #2077

@googlebot I signed it!

@joeyparrish I have added unit tests and refactored the existing unit tests in test/media/region_timeline_unit.js. Hope it is okay.

Thanks so much for your contribution!


PATCH body?

Does the PATCH method not include a way to send the body like POST and PUT?

Hi synth3tk, how can you do it?
My code is not working
var headers = {
  "Authorization": "token " + accessToken,
  "Content-Type" : "application/json"
};

var id = "12345678";

var updatedData = {
  description: 'update doc',
  public: true,
  files: {
    'updated.md': { content: 'updated' }
  }
}

rest
  .patch(
    "https://api.github.com/gists/" + id,
    {
      data: JSON.stringify(updatedData)
    },
    {
      headers: headers,
    })
    .on('complete', function(result){
      console.log(result);
    })


There is no way to check if a LuaTable has a key

LuaTable has set and get methods, but no "has" methods (or somehing like that). How is one supposed to know whether a getcall succeeded or just gave null?

added "has" method for Luatable in new version


scopes (*) are skipped

Describe the bug
A clear and concise description of what the bug is.
When commit scope is (*) or * it isn't generated
To Reproduce
Steps to reproduce the behavior:

commit with something like feat(*): user authentication
generate
missing

Expected behavior
the item get added with default_scope and to be treated as if it's feat: user authentication
System (please complete the following information):

OS Information: MacOS
Project Version: [0.4.0]

Additional context
cliff configuration: https://gist.github.com/tami5/1044c256a173c622847114cc3bcd0ffd

Hello! I can't reproduce this.
When I have feat(*): user authentication in my commit history, I can generate the following changelog with the config you provided:
# Changelog

# [unreleased](https://github.com/orhun/git-cliff)

## ✨ Features

##### (*)

- <tt>411a6f7</tt> User authentication

Or did you mean something else while saying "it isn't generated"? Do you want to assume that these type of commits have a general scope (and is that the reason why you used *?) Can you please elaborate your use-case?

Hello! I can't reproduce this.
When I have feat(*): user authentication in my commit history, I can generate the following changelog with the config you provided:

# Changelog

# [unreleased](https://github.com/orhun/git-cliff)

## ✨ Features

##### (*)

- <tt>411a6f7</tt> User authentication

Or did you mean something else while saying "it isn't generated"? Do you want to assume that these type of commits have a general scope (and is that the reason why you used *?) Can you please elaborate your use-case?

Oh that's odd, It didn't generate in my case at all, can I invite you to the repo? I'd make it public but isn't ready yet.
Yes, in my use case and for consistency reasons I donate the general scope with (*), instead of the total omission the parentheses. I think this common enough to treat it as if it's written like feat: user authentication

Oh that's odd, It didn't generate in my case at all, can I invite you to the repo? I'd make it public but isn't ready yet.

Sure, or you can share a snippet from the commit history if that's alright. It depends on how you want me to test this.

Yes, in my use case and for consistency reasons I donate the general scope with (*), instead of the total omission the parentheses. I think this common enough to treat it as if it's written like feat: user authentication

I see. Well, in this case, having (*) in the changelog is not really what you want then. It should be somehow overrode to remove/replace the scope. However, this is not currently possible because there isn't a commit pre-processing mechanism implemented in git-cliff yet.

Commit preprocessors feature has been implemented.


[Extensibility Request] Codeunit 20 - "Posting Preview Event Handler". Adding subscriber event "OnAfterModifyEvent" to the "FA Ledger Entry" table.

We have a problem when recording documents related to fixed assets in the "Preview" mode. We need to reevaluate fixed assets and change entries in the table "FA Ledger Entry". Please, add a subscriber event "OnAfterModifyEvent" for the "FA Ledger Entry" table.
`
[EventSubscriber(ObjectType::Table, Database::"FA Ledger Entry", 'OnAfterModifyEvent', '', false, false)]
local procedure OnModifyFALedgEntry(var Rec: Record "FA Ledger Entry"; RunTrigger: Boolean)
begin
if Rec.IsTemporary() then
exit;
TempFALedgEntry:= Rec;
TempFALedgEntry."Document No." := '***';

if TempFALedgEntry.Modify() then
    PreventCommit();

end;
`
Thanks in advance!

Hi,
What is the reason why you can't use subscriber and implement logic that you need?

Hi,
This codeunit uses the TempFALedgEntry variable.
The variable is populated by the "insert" record subscriber, but the variable is not updated by the "modify" record subscriber.
There is no way to replace the TempFALedgEntry variable in this codeunit.
Therefore, I ask you to add a “modify” subscriber to update this variable.
The idea is to do it similarly to other variables, for example TempCustLedgEntry, TempVendLedgEntry.
Thanks.


[Bug][Connector-v2][KafkaSink][KafkaSink failed to commit transactions under EXACTLY_ONCE semantics]

Purpose of this pull request

#4247
When KafkaSink starts Exactly once and no data is written to the topic during a checkpoint, the transaction commit exception is triggered, with the following exception.

If data is written during the checkpoint, this exception will not occur.
After the transaction attribute transactionStarted is changed to false, whether there is data writing or not will not affect the transaction commit.
Check list

[ ] Code changed are covered with tests, or it does not need tests for reason:
[ ] If any new Jar binary package adding in your PR, please add License Notice according
New License Guide
[ ] If necessary, please update the documentation to describe the new feature. https://github.com/apache/incubator-seatunnel/tree/dev/docs
[ ] If you are contributing the connector code, please check that the following files are updated:

Update change log that in connector document. For more details you can refer to connector-v2
Update plugin-mapping.properties and add new connector information in it
Update the pom file of seatunnel-dist

[ ] Update the release-note.

@ruanwenjun @Hisoka-X @TyrantLucifer PTAL.

@EricJoy2048 @ruanwenjun @ashulin @TaoZex @Hisoka-X PTAL.

There is a problem under the consume mode of read_committed. This cannot be modified in this way. I will close this pr, but this is indeed a valid issue.


[WIP - DO NOT MERGE] Update package dependencies

Install python3-devel and do not download podman-* packages as they can
be fetched from dnf.
oci-umount should no longer be needed.
Fixes: #159 and #161
Signed-off-by: Lokesh Mandvekar<EMAIL_ADDRESS>

@cevich shouldn't this respond with image build info or did that change in the last few days?

@cevich shouldn't this respond with image build info or did that change in the last few days?

It should, unless the bot broke.  I'll take a look.

Hrmmm, appears like it broke but the reason is not clear.  I'll try re-running it.

Nevermind, I can just copy-paste:

Name
ID

build-push
build-push-c5183905157349376

fedora
fedora-c5183905157349376

fedora-aws
ami-0385e874621[24](https://github.com/containers/automation_images/runs/7959518644?check_suite_focus=true#step:13:24)f700

fedora-netavark
fedora-netavark-c5183905157349376

fedora-netavark-aws-arm64
ami-0b1b2a08[27](https://github.com/containers/automation_images/runs/7959518644?check_suite_focus=true#step:13:27)39f9c9a

fedora-podman-aws-arm64
ami-001a9db2efa37ff41

fedora-podman-py
fedora-podman-py-c5183905157349376

prior-fedora
prior-fedora-c5183905157349376

ubuntu
ubuntu-c5183905157349376

@cevich does this need testing of all repos before merge or only https://github.com/containers/podman/pull/15436 ?

I think podman should be good enough.

On second thought, since you're changing the download contents, it's worth at least looking through the CI setup of Buildah and Skopeo (and maybe others) to see if those packages are explicitly referenced somewhere.

podman: https://github.com/containers/podman/pull/15436
skopeo: https://github.com/containers/skopeo/pull/1739
buildah: https://github.com/containers/buildah/pull/4201

Just remembered, if you're updating Skopeo, you've got to hit containers/image  as well.

c/image: https://github.com/containers/image/pull/1639

Hmmm...dangit bot, why no table?!?!?!?

okay bot will be fixed momentarily.

ugh...stooopid github actions.  I can't fix it for this PR.
The images suffix is c5124654741323776 for the most recent build.

skopeo and c/image are still failing with the latest image suffix. Only thing that comes to mind is adding back oci-umount. I thought oci-umount was dead.

Ugh, the bot is broken again :cry:

Fixed.  It was just a quay Error: Server Error

@lsm5 is this PR stuck?

@lsm5 is this PR stuck?

na, distractions galore.

@cevich looks like fedora 35 is failing because of an older golang. Can we ignore f35 in this PR?

Done :grin:

@lsm5 I think we can perhaps just merge this PR.  But correct me if I'm wrong, you already confirmed these changes work with podman/buildah, eh?  If so, the c/skopeo problem isn't specific to this PR's changes, I'm hitting it in my F37 image update PR also: https://github.com/containers/skopeo/pull/1821

@lsm5 I think we can perhaps just merge this PR. But correct me if I'm wrong, you already confirmed these changes work with podman/buildah, eh? If so, the c/skopeo problem isn't specific to this PR's changes, I'm hitting it in my F37 image update PR also: containers/skopeo#1821

IIRC, yes, this did work with podman and buildah. I can give this another run though just to get it up to date.

Attempting to re-run the prior-fedora tasks...maybe it worked?

The prior-fedora cache-image build is failing because the base-image isn't finished yet..  Once that goes green, the cache-image build can be re-run and should pass.  Doing it this way will preserve the $IMAGE_SUFFIX value so no downstream .cirrus.yml changes will be needed.

Pressed the prior-fedora cache-image re-run button.

podman PR at https://github.com/containers/podman/pull/15436 . quite some changes were needed. still going through some flakes.

@lsm5 Paul has a PR open to update images, it probably addresses most/all the flakes.  I suggest waiting for his to merge.  Then yours will be much easier after rebase.

Paul's PR merged.  Bringing this into podman should be easy...but you probably need to rebase this PR and rebuild images again :sob: There were some significant changes merged to the windows VMs (in this repo, and podman CI) that will break things if not carried forward.

Re-ran fedora-aws Base Image job - ssh timeout.  I've been seeing this more and more frequently the last few days.  No idea what's causing it.  Wouldn't be surprised if it's Mr. Bozos himself just messing with our heads for the grins.

Can this be merged now or should we wait for https://github.com/containers/podman/pull/15436?  I don't think any more changes in this PR should be needed. No?

@cevich i'll let you decide. I'm fine with merging before podman PR :)


Skipped ban of single connection in connection pool

I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en

Pull request type

Please check the type of change your PR introduces:

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, renaming)
[x] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Documentation content changes
[ ] Other (please describe):

What is the current behavior?

Issue Number: N/A
What is the new behavior?

Other information

Codecov Report
Base: 62.72% // Head: 44.44% // Decreases project coverage by -18.29% :warning:

Coverage data is based on head (68706a3) compared to base (b55b6e3).
Patch has no changes to coverable lines.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@             Coverage Diff             @@
##           master     #573       +/-   ##
===========================================
- Coverage   62.72%   44.44%   -18.29%
===========================================
  Files         221      147       -74
  Lines       21539    15388     -6151
===========================================
- Hits        13511     6839     -6672
- Misses       7356     8238      +882
+ Partials      672      311      -361

Flag
Coverage Δ

1.16.x
44.10% <ø> (-18.24%)
:arrow_down:

1.19.x
44.45% <ø> (-17.99%)
:arrow_down:

1.20.x
44.47% <ø> (-18.10%)
:arrow_down:

insecure
?

integration
?

macOS-latest
44.42% <ø> (ø)

secure
?

ubuntu-latest
44.41% <ø> (-18.28%)
:arrow_down:

unit
44.44% <ø> (-0.05%)
:arrow_down:

windows-latest
?

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

 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.


admob Delegate not firing

The pauseTasks() and resumeTasks() are not firing for admob ads
If have set the delegate to self - and all is working fine for iAd as can be seen in the debug trace
DEBUG iAds banner did load, showing
DEBUG iAds banner clicked
DEBUG pauseTasks
DEBUG iAds banner closed
DEBUG resumeTasks
but for admod I only get
DEBUG AdMob banner did load, showing
This indicates the following function is never being called
func adViewWillPresentScreen(bannerView: GADBannerView!) {
Debug.print("AdMob banner clicked")
delegate?.pauseTasks()
}
any help appreciated

Hey, I will have a look. I just fixed the orientation stuff. Sorry again

I have found a workaround for this based on admob documentation - but it would be nicer if the delegate worked
admob documentation
//    Pausing and resuming the app
//
//    GADBannerViewDelegate has events to notify you when an click causes an overlay to be                          presented or dismissed, or invokes an external browser. If you want to know that these events happened because of ads, then register for these GADBannerViewDelegate methods.
//
//    But to catch all types of overlay presentations or external browser invocations, not just  ones that come from ad clicks, your app is better off listening for the equivalent methods on UIViewController or UIApplication. Here is a table showing the equivalent iOS methods that are invoked at the same time as GADBannerViewDelegate methods.
//    GADBannerViewDelegate method	iOS method
//    adViewWillPresentScreen:        UIViewController's viewWillDisappear:
//    adViewWillDismissScreen:        UIViewController's viewWillAppear:
//    adViewDidDismissScreeen:        UIViewController's viewDidAppear:
//    adViewWillLeaveApplication:     UIApplicationDelegate's applicationDidEnterBackground:
override func viewWillAppear(animated: Bool) {
    super.viewWillAppear(animated)
    print("viewWillAppear")
}

override func viewDidAppear(animated: Bool) {
    super.viewDidAppear(animated)
    print("viewDidAppear")
}

override func viewWillDisappear(animated: Bool) {
    super.viewWillDisappear(animated)
    print("viewWillDisappear")
}

override func viewDidDisappear(animated: Bool) {
    super.viewDidDisappear(animated)
    print("viewDidDisappear")
}

func applicationWillResignActive(notification: NSNotification) {
    print("I'm out of focus!")

}

func appMovedToBackground() {
    print("App moved to background!")
}

//==================================================================
//  OUTPUT
//==================================================================
//    application didFinishLaunchingWithOptions
//    Google Mobile Ads SDK version: afma-sdk-i-v7.6.0
//    viewWillAppear
//    applicationDidBecomeActive
//    viewDidAppear
//    adViewDidReceiveAd
//    applicationWillResignActive
//    I'm out of focus!
//    App moved to background!
//    applicationDidEnterBackground
//    applicationWillEnterForeground
//    applicationDidBecomeActive
//==================================================================

Thanks, I am just looking at the delegates. Its weird because all the interstitial delegates fire and the banner error delegate also fires. Its just those 2 delegates that dont.

It seems those 2 delegates dont fire unless you are using modalViews. I dont really know what that means but for now I just added two custom methods
/// AdMob Custom methods (2 delegates dont get called)
func adMobBannerClicked() {
    Debug.print("AdMob banner clicked")
    delegate?.pauseTasks()
}

func adMobBannerClosed() {
    Debug.print("AdMob banner closed")
    delegate?.resumeTasks()
}

which you call in your app delegate like you said. I am still reading to see if I can use the delegates. For now I push the new update anyway

excellent. thanks

Check the other question as well for the correct answer.

one other minor issue - didn't want to open a new issue ticket for this.
The following code can't work
If you are NOT in debug mode - it should run the code
    #if !DEBUG
        Debug.print("Ads in live mode")
        adMobBannerAdID = AdMobUnitID.Banner.live
        adMobInterAdID = AdMobUnitID.Inter.live
    #endif

but the Debug.print all has an #If debug clause - which means it will not print
    #if DEBUG
        Swift.print("DEBUG", object) //, terminator: "")
    #endif

You mean the line
  Debug.print("Ads in live mode")

line?
Yeah true that won't work, lol.

Is there a way to stop Inter ads from loading ?
My app will only use banner ads - so I don't want it to load any Inter ads

Go to the helper and to the init method and comment out this block which preloads the InterAds the first time.
if iAdsAreSupported {
        iAdInterAd = iAdLoadInterAd()
    }
    adMobInterAd = adMobLoadInterAd() // always load adMob

did you ever get any further in resolving this issue ?
Is this just the issue of using Modal views ?

Hey,
I didnt get any further unfortunately, have been busy finishing my latest game and its taking all my time.
I think as far as I understand they will only fire using modalViews as per googles documentation.
I will keep this question open for now.
Thanks again for your support and for using my helper

Hey, I was just doing some work on my helper. It turns out the delegates are working if you are in release mode. They only dont seem to work in test mode.
https://groups.google.com/forum/#!topic/google-admob-ads-sdk/VDWT6maYbPY
I will close this question.


Update SRS and VnV traceabilty matrices - Once all other updates complete

Documents:
SRS, VnV Plan
Changes:
Update both traceability matrices to match updates based on feedback once all updates complete.
Checklists:

[ ] Update SRS traceability matrix
[ ] Update VnV Plan traceability matrix

Due Date:
Feb 5, 2024

Completed in commit id: fd684242dc1584248227078c482b651bbb1c9a8c


OS X falls apart ...

Wont work on OS X
% gleshys start
Using temporary settingsfile: /var/folders/yt/rgx_xnvn2ld4qr5trt0_67jm0000gn/T/gleshys.XXXXXX.WrYErsPB
Use the configuration file option for other tools to find it.

GleSYS Login
==========================================

Username<EMAIL_ADDRESS>Password:
/Users/senare/repos/3rd/gleshys/bin/gleshys-start: line 90: mapfile: command not found
fail
{
  "response": {
    "status": {
      "code": 1601,
      "timestamp": "2020-12-07T09:25:15+01:00",
      "text": "Login Failed",
      "transactionid": null
    },
    "debug": {
      "input": {
        "username"<EMAIL_ADDRESS>        "password": "verySecretctAndLongPassword"
      }
    }
  }
}
fail

Indeed.
mapfile was introduced in bash 4. OS X uses an old bash 3 version because of licensing.
https://tldp.org/LDP/abs/html/bashver4.html

The new mapfile builtin makes it possible to load an array with the contents of a text file without using a loop or command substitution.

Something to add to dep-check as that’s a hard known fact.


Tabs focus state cropped in IE11

IE11 in Browserstack shows the focus correctly but in IE11 on native Windows 7 and 10 the focus appears cropped:

Edge on native Windows 10 displays the focus state correctly.

This could be related to https://github.com/alphagov/govuk-frontend/issues/1469#issuecomment-505538016, although I can't replicate this on Chrome on Windows.

It doesn't look like this is related to https://github.com/alphagov/govuk-frontend/issues/1469#issuecomment-505538016. It's more likely because the way we do the focus state for the tabs is quite a complex use of box shadow (to avoid a breaking change).


[ISSUE #927]📝Update README.md

Which Issue(s) This PR Fixes(Closes)

Fixes #927
Brief Description

How Did You Test This Change?

🚀Thanks for your contribution🎉. CodeRabbit(AI) will review your code first🔥


removes all deprecate warning in CI

https://github.com/web-infra-dev/rspack/actions/runs/7261029436/job/19781998400#step:5:77
some of the test cases are still using deprecated configuration which should be migrated to new configuration

please assige to me

resolved by #5127


fix texparameters for mipmapping

defaulting min filter to GL_LINEAR_MIPMAP_NEAREST. and disable it internally if not applicable.
tested with 3dcursor, cubemap, shadows, render-to-texture, solarsystem, multilight, performance.

@NolaDonato please review it.

Breaks gvr-modelviewer:

        "3.7.14 External Textures

        External textures cannot be used with TexImage2D, TexSubImage2D,
        CompressedTexImage2D, CompressedTexSubImage2D, CopyTexImage2D, or
        CopyTexSubImage2D, and an INVALID_ENUM error will be generated if this
        is attempted.  Their default min filter is LINEAR.  It is an
        INVALID_ENUM error to set the min filter value to anything other than
        LINEAR or NEAREST.

tested with all the demos. External textures are using two different types of images. I had missed one of it.


Suggestion: clarify documentation around blocking event loop or dispatch calls to external code in separate threads

Let's say we have a Redis instance with a bunch of lists with keys of the form inbox::<integer>. We want to print all of the inboxes we can find and the number of messages in each. Here's an extremely simple application (please ignore the part where we're not advancing the scan cursor) that's intended to do exactly that, but will fail due to a RedisCommandTimeoutException:
public static void main(final String... args) {
    final RedisClient redisClient = RedisClient.create("redis://localhost:6379");
    redisClient.setDefaultTimeout(Duration.ofSeconds(2));

    try (final StatefulRedisConnection<String, String> connection = redisClient.connect()){
        final RedisCommands<String, String> commands = connection.sync();

        commands.scan(key -> {
            // We'll get a timeout on the next line
            System.out.format("Found inbox %s with %d messages\n", key, commands.llen(key));
        }, ScanCursor.INITIAL, ScanArgs.Builder.matches("inbox::*"));
    }
}

Now, I know why that happens (I'm making a blocking call via commands.llen on a Netty IO thread), but it's unlikely to be obvious to newcomers to Lettuce (or Netty, for that matter, and I'm willing to bet that most Lettuce users aren't Netty experts). This can also happen in just about any situation where Lettuce executes non-Lettuce code via some kind of callback. Pub/sub listeners are another prime example.
I think there's room for improvement in this situation. The Lettuce reference docs do, in the section about consuming futures, call out:

Lettuce futures are completed on the netty EventLoop. Consuming and chaining futures on the default thread is always a good idea except for one case: Blocking/long-running operations. As a rule of thumb, never block the event loop. If you need to chain futures using blocking calls, use the thenAcceptAsync()/thenRunAsync() methods to fork the processing to another thread.

…but it's not obvious from that section that the rule also applies to callbacks from the synchronous API. One possible improvement would be to add a section to the docs that explicitly calls out the "don't make blocking calls including synchronous Lettuce calls inside callbacks from Lettuce." Similar advice would also be helpful for the Javadoc for methods in the synchronous API that call user code (scan callbacks, pub/sub listeners, etc.).
At the same time, it seems like there's an opportunity to avoid the situation entirely. If a user is calling code via the synchronous API, there's a very good chance they intend to use the synchronous API for other things, too. If they do that inside the callback, things WILL block and time out. While making blocking calls in general will degrade performance and can cause things to time out, making synchronous Lettuce calls in particular is guaranteed to block the whole connection until the offending command times out. The combination "easy to miss," "likely to happen," and "severe impact" makes me think it might be worthwhile to do more than adding a warning in the docs.
Could Lettuce dispatch calls to user code to a separate thread to avoid the problem entirely? It may be that the computation thread pool makes sense in this case (I'm not really familiar with the use cases for the computation pool yet, so this may be a terrible suggestion!). It may also make sense to introduce a new thread pool just for callbacks from the synchronous API, or to provide a way for callers to specify their own Executor when making synchronous calls (something analogous to CompletableFuture#runAsync(Runnable, Executor), maybe).
Cheers, and thanks for your consideration!

Pub/sub listeners are another prime example.

And as if on cue, that seems to be exactly what's happening in #1407.

Pub/sub listeners are another prime example.

And as if on cue, this seems to be exactly what's happening in #1407.

Thanks for bringing up this topic. We updated the Streaming API/Pub/Sub documentation sections to avoid blocking calls in callbacks.
By using the EventLoop for callbacks we ensure proper backpressure propagation and a sense of synchronization. If we would  issue callbacks on a separate threadpool, then we cause the following effects:

Loss of backpressure (i.e. the threadpool could be easily overloaded with tasks as they are enqueued without having a back channel to the actual source of data that would throttle task creation if the consuming side doesn't catch up)
Context switching (i.e. we have no guarantee to run tasks on the same thread. This can easily cause context loss when code uses ThreadLocal storage and visibility issues when mutating improperly guarded data structures)

The number of possibilities to block the eventloop is next to infinite (synchronized blocks, Locks, blocking calls, …) so we cannot easily catch all of these. A general recommendation is to use BlockHound to detect blocking calls.

Loss of backpressure…
Context switching…

Fair enough. That makes sense to me.

The number of possibilities to block the eventloop is next to infinite (synchronized blocks, Locks, blocking calls, …) so we cannot easily catch all of these.

Sure. I think that's fair, but I still think Lettuce is in a uniquely strong position to cause a particularly nasty flavor of blocking. I think the documentation update makes sense, but how would you feel about going farther and adding something to the API docs for the various methods that add listeners, to the listeners themselves, and to methods that otherwise call potentially-blocking user-provided code from the event loop? I'd be happy to open a pull request if you're open to it!
The main thing I'd want to achieve is clarifying to users that something is happening on the event loop since there isn't currently a great way of identifying event loop entry points without reading the source code. Even callers who understand that they shouldn't block the event loop may not realize that they're on the event loop in the first place, and I think calling that out could make a big difference.
Cheers, and thanks for the thoughtful reply!

I also had that thought. Do you want to submit a pull request? A lot of the API is generated so it's fine to add Javadoc to files in src/template.

Sure! This is a pretty full week for me, but I'll hope to knock it out in the next few days.

Closing due to lack of activity. If you would like us to look at this issue, please provide additional information and we will re-open the issue.


Hidden Input Opacity Not Changed On Blur(CSS Bug)

when i click on the input and then click on outside the input, input opacity is not changed.

Ah, interesting. I'll take a look, but feel free to raise a pr also.

@martinpengellyphillips I'm just starting to learn SolidJS. Can I check this out ?

Closing as superseded by 0.14.0 - the input is no longer hidden with opacity. Instead only the caret is hidden or not.


docs: blueprint MUST be registered after before_request handler

see https://cmsdk.com/python/flask-doesn39t-call-blueprint39s-beforerequest-function.html

Your change is live! https://flask-sse.readthedocs.io/en/latest/advanced.html#access-control
Thanks for the pull request ✨


new(rules): add umount macro

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area rules

/area registry

/area build

/area documentation

What this PR does / why we need it:
add new umount macro
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: incertum
Once this PR has been reviewed and has the lgtm label, please assign lucaguerra for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

My only concern of adding macros that are not used in rules is that Falco will return the "XXX macro is not used" warning when processing the ruleset for validation.

Agree with Jason here, we could comment it and leave it as a hint for users, WDYT?

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: incertum, jasondellaluce
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [jasondellaluce]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

LGTM label has been added.  Git tree hash: 3a51bc6d2713a4f4e3c9b15672497070d5fe086f


The hand-written tests is deleted on re-generation

Steps to reproduce

Regenerate the ruby client codes

$ cd kubernetes-client/gen/openapi
$ ruby.sh path/to/kubernetes-client/ruby/kubernetes/ path/to/kubernetes-client/ruby/settings

...
...
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 20.620 s
[INFO] Finished at: 2019-02-17T08:56:27Z
[INFO] ------------------------------------------------------------------------
---Done.
---Done.

Some diffs exists in the generated codes

$ cd path/to/kubernetes-client/ruby/
$ git status

On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   kubernetes/kubernetes.gemspec
        modified:   kubernetes/lib/kubernetes.rb
        deleted:    kubernetes/lib/kubernetes/api_client.rb
        deleted:    kubernetes/lib/kubernetes/config/error.rb
        deleted:    kubernetes/lib/kubernetes/config/incluster_config.rb
        deleted:    kubernetes/lib/kubernetes/config/kube_config.rb
        deleted:    kubernetes/lib/kubernetes/utils.rb
        deleted:    kubernetes/spec/config/incluster_config_spec.rb
        deleted:    kubernetes/spec/config/kube_config_spec.rb
        deleted:    kubernetes/spec/config/matchers.rb
        deleted:    kubernetes/spec/fixtures/config/kube_config_hash.rb
        deleted:    kubernetes/spec/fixtures/files/certs/ca.crt
        deleted:    kubernetes/spec/fixtures/files/certs/client.crt
        deleted:    kubernetes/spec/fixtures/files/certs/client.key
        deleted:    kubernetes/spec/fixtures/files/config/config
        deleted:    kubernetes/spec/fixtures/files/config/empty
        deleted:    kubernetes/spec/fixtures/files/tokens/token
        deleted:    kubernetes/spec/helpers/file_fixtures.rb
        deleted:    kubernetes/spec/utils_spec.rb

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        kubernetes/swagger.json.unprocessed

deleted:    kubernetes/spec/config/incluster_config_spec.rb
deleted:    kubernetes/spec/config/kube_config_spec.rb
deleted:    kubernetes/spec/config/matchers.rb
deleted:    kubernetes/spec/fixtures/config/kube_config_hash.rb
...

I guessing that the deleted files under spec folder are hand-written codes, and those were deleted by the code generation step here.
Suggestion
I think generating spec files is not necessary as the auto-generated files under spec are just skelton.

Remove spec from here
Configure the exclusion for spec files in ruby.xml

What do you think about it? I would file a PR if the suggestion is OK.

https://github.com/kubernetes-client/gen/pull/104 has been merged. 😌


Handle task weights

Fixes #2651
tasks attribute of TaskSet/User is now a mapping from tasks to their weights.
All other utility functions, like tag, get_tasks_from_base_classes, filter_tasks_by_tags take this into account in their recursion.
gen_next_task now uses random.choices to sample the tasks according to weights. Necessary cumulative weights are pre-computed in __init__.
The check of whether there are no tasks is now performed at __init__, instead of doing it on every call to gen_next_task.
Additionally, the DefaultTaskSet class is removed because it was only necessary to override two functions where self.user should be used instead of self when used directly inside a User. User now uses a TaskSet internally, and TaskSet now checks if it is being used by the User or nested in another TaskSet to make the correct choice.
Currently, this is a draft PR because only the backend itself is changed. Please let me know if the changes are understandable so far, and then I will proceed to change the tests and documentation to reflect this.

I see based on the failed tests already that if TaskSet is instantiated in User then the check of empty tasks in __init__ will raise an error. There is a simple fix for that, will add it soon

Hi - looks like I reviewed your PRs out of order :)
I will do a full review once the build is green.
I do get some errors out of the box running for example examples/locustfile.py.
[2024-05-27 19:06:22,011] Larss-MacBook-Pro/INFO/locust.runners: Ramping to 1 users at a rate of 1.00 per second
[2024-05-27 19:06:22,012] Larss-MacBook-Pro/INFO/locust.runners: All users spawned: {"QuickstartUser": 1} (1 total users)
Traceback (most recent call last):
  File "src/gevent/greenlet.py", line 908, in gevent._gevent_cgreenlet.Greenlet.run
  File "/Users/lars/git/locust/locust/user/users.py", line 189, in run_user
    user.run()
  File "/Users/lars/git/locust/locust/user/users.py", line 147, in run
    self._taskset_instance = TaskSet(self)
                             ^^^^^^^^^^^^^
  File "/Users/lars/git/locust/locust/user/task.py", line 293, in __init__
    raise Exception(
Exception: No tasks defined on TaskSet. Use the @task decorator or set the 'tasks' attribute

Also DefaultTaskSet is used in other places (like locust-plugins), so maybe we leave an implementation there for a while and just mark it deprecated?

Oh, and one more thing, would this change impact the "Current ratio" tab in the UI? (http://<IP_ADDRESS>:8089/?tab=ratios)

@cyberw

I will do a full review once the build is green.

Okay, then I will work further on fixing the tests. Will take some time.

Oh, and one more thing, would this change impact the "Current ratio" tab in the UI? (http://<IP_ADDRESS>:8089/?tab=ratios)

Does this get the data from this module? https://github.com/locustio/locust/blob/master/locust/user/inspectuser.py
If so, those functions are fixed internally to account for the dictionary of tasks to weights, but the interface and output should remain equivalent. If these are tested, once the build is fixed it should be ok.

Hi @bakhtos have you had any time to look at this? :)

Hi @cyberw !
I started looking into fixing the tests for other PRs that I prepare here, and then I had a busy time at work.
Next week I am almost free from work, so I hope to finalize these PRs.


Increase the scrollable area for viewing the mapped predicates

Might as well use the available screen space to help users view the mapping and assign predicates, as the main purpose of the DESM tool.

@excelsior - Please increase the vertical size of this scroll window (and make it possible for the user to expand it further if necessary).

changed layout