Blueprint with a set url_prefix wont allow POST requests

Considering the following snippet, the GET request works perfectly. But the POST request results in sanic.exceptions.InvalidUsage: Method POST not allowed for URL /api/failing. This seems to be specific when url_prefix is set.
from sanic import Sanic, Blueprint
from sanic.response import text, json

app = Sanic()

failing_bp = Blueprint('failing_blueprint', url_prefix='/api/failing')

@failing_bp.get("/")
async def get_data(request):
    return json({
        "hello": "world",
        "I am working if": "you see me",
        "from": "the failing blueprint"
    })

@failing_bp.post("/")
async def post_data(request):
    return text("POST [FAILING] - {}\n\n{}".format(
        request.headers,
        request.body
    ))

if __name__ == "__main__":
    app.blueprint(failing_bp)

    app.run(debug=True, host="<IP_ADDRESS>", port=8000)

The extra weird part, is that if you were to comment out (or remove) the GET request from the blueprint, the POST request works pefectly fine.
I've got a super small repository that highlights this if you want to mess with it yourself.
https://github.com/mattfinnell/sanic-blueprints
EDIT : User mateusz_b on the python slack channel stated that this had to deal with an issue regarding trailing slashes in the url. Performing the post request with a trailing slash allowed it to work just fine, but there seems to be quite a bit of odd behavior behind this. Especially considering that an endpoint with a non-trailing slash will only work if the POST request is the ONLY route in the blueprint.

I thought I fixed this already. Will have to look again soon. Thanks for reporting.


fix panel bug

allow the user to select objects in the world and have them show in the object panel.
Reference: https://github.com/webaverse/app/issues/3112
https://user-images.githubusercontent.com/60634884/172517162-5fb33315-7aab-435a-8aa8-8574d3175491.mp4

move world object select to game.js

move world object select to game.js

Hello @tcm390 is this ready to be pulled in? Could you please resolve the packages/three conflict?
@alisaad673 has this been resviewed?

@avaer reviewed this, works good
cool if we pull this?

Hey @lalalune  @tcm390  Sorry I missed the review request.
I have tested this,
the functionality seems to be working fine, except this one bug:
-While we select any object from world and edit it, After we close the world panel, there still is the pointer for selecting the objects also there is this position pointer too. We are unable to click into the world and unable to move camera direction. This  happens only when we try to close the panel with mouse. Doesn't happens when we close the panel with "Z" key.
https://user-images.githubusercontent.com/35926530/177983287-e120daf7-b1ae-40d3-ac03-1ca4c32a64ff.mp4
https://user-images.githubusercontent.com/35926530/177983775-23bfd5ca-6c31-4a8b-9781-86fd12fd36b6.mp4

Close in favor of https://github.com/webaverse/app/pull/3262/


 I cannot click to play that Surah for Qari B.

@mmahalwy This has been fixed on beta.quranicAudio.com

Ah, nice :) Didn't notice
Thank you!


request/question: is there a way for debug to log to a file?

based on the readme, i do not see a way for debug to log to a file.

yep, you can:
$ DEBUG_FD=3 node your-app.js 3>whatever.log

and all debug statements will be piped into whatever.log

I was looking for the same thing and I just stumbled here. This is something really useful to know. Should it be mentioned on the README perhaps? I could make a quick PR if the answer is yes.

Yes
On Wednesday, April 1, 2015, Daniel Ochoa<EMAIL_ADDRESS>wrote:

I was looking for the same thing and I just stumbled here. This is
something really useful to know. Should it be mentioned on the README
perhaps? I could make a quick PR if the answer is yes.
—
Reply to this email directly or view it on GitHub
https://github.com/visionmedia/debug/issues/192#issuecomment-88631770.

I'm attempting to do this now, and It makes not working.
Here's what I've been trying, which could be used to make more helpful docs.
thomas@workstation:node-image-learning$ DEBUG_FD=3 DEBUG=* node -e 'var debug = require("debug")("test"); debug("hello world")' > temp.txt
events.js:141
      throw er; // Unhandled 'error' event
            ^
Error: write EBADF
    at Object.exports._errnoException (util.js:749:11)
    at exports._exceptionWithHostPort (util.js:772:20)
    at WriteWrap.afterWrite (net.js:753:14)
thomas@workstation:node-image-learning$ DEBUG_FD=3 node -e 'var debug = require("debug")("test"); debug("hello world")' > temp.txt
thomas@workstation:node-image-learning$ DEBUG_FD=3 node -e 'var debug = require("debug")("test"); debug("hello world")' 3> temp.txt
thomas@workstation:node-image-learning$ DEBUG_FD=* node -e 'var debug = require("debug")("test"); debug("hello world")' *> temp.txt
thomas@workstation:node-image-learning$ DEBUG_FD=test node -e 'var debug = require("debug")("test"); debug("hello world")' test> temp.txt

Also posted this stackoverflow question.

Thought it might have something to do with  the eval (-e) and not running from a file and tried all the following, with no luck as well.
thomas@workstation:node-image-learning$ DEBUG_FD=3 node log.js 3> temp.txt
thomas@workstation:node-image-learning$ DEBUG_FD=3 node log.js > temp.txt
thomas@workstation:node-image-learning$ DEBUG_FD=3 node log.js
thomas@workstation:node-image-learning$ DEBUG=* node log.js
  test hello world +0ms
 thomas@workstation:node-image-learning$ DEBUG_FD=3 node log.js 3> temp.txt
thomas@workstation:node-image-learning$ DEBUG_FD=3 node log.js > temp.txt
thomas@workstation:node-image-learning$ DEBUG_FD=3 node log.js
thomas@workstation:node-image-learning$ DEBUG=* node log.js
  test hello world +0ms

@reggi this works fine:
stephenmathieson at MBP in /tmp/debug-192
$ DEBUG_FD=3 DEBUG=foo node -e "require('debug')('foo')('hello')" 3> foo.txt
stephenmathieson at MBP in /tmp/debug-192
$ cat foo.txt
Sat, 04 Apr 2015 15:45:35 GMT foo hello
stephenmathieson at MBP in /tmp/debug-192

@stephenmathieson Thanks for the clarification, I believe I was behind a version when I used both DEBUG_FD and DEBUG together I got that error. Then when I upgraded I stopped using DEBUG and wasn't getting any output. Its working now, thanks a bunch! :banana: :banana: :banana: :banana: :banana:

@reggi glad it's figured out

I've stuck with the same problem with only one difference. If I'm running my application with node - everything is cool and debug works, but if I runnig my application with nodemon - I receive exactly the same error.
Any advises?

hello.is it possible to do something like that on windows ?thanks!


wip: what is in this old series of changes?

the only changes are the date so it must just be an older dump.


var = begin causes symbols to go away

If I have a block in my ruby file:
result = begin
  something_something
  something_else
end
result.save

All the ruby symbols in the file go away

When I remove that block, the symbols come back

@jacquescrocker try the new version 0.1.6

Works now, thanks Miguel!


Lack of chainID validation allows re-using signatures across forks

Severity: High
Difficulty: High
Description
Calling UnderwriterToken.permit allows an asset holder to move tokens on behalf of another user by using a signature. The lack of chainId verification on every signature can enable an attacker to withdraw rewards multiple times if the chain is forked.
UnderwriterToken.permit uses ecrecover to allow changing the approval of users:
https://github.com/keep-network/coverage-pools/blob/4aee098edbd4755d57dcfc7649ca80ab105500bb/contracts/ERC20WithPermit.sol#L101-L146
A domain separator and the chainID are included in the signature scheme when the contract is deployed:
https://github.com/keep-network/coverage-pools/blob/4aee098edbd4755d57dcfc7649ca80ab105500bb/contracts/ERC20WithPermit.sol#L48-L61
However, this chainID is read at the time of deployment. In the event of a post-deployment chain hard fork, the chainID cannot be updated, and signatures may be replayed across both versions of the chain. As a result, an attacker could reuse signatures to receive user funds on both chains.
Exploit Scenario
A fork of mainnet is performed on Eth 2.0. The tokens on the old chain lose their value, but they keep the same value on the new chain. Bob allows Eve to transfer its tokens on the old chain. Eve uses the signature to also withdraw the tokens on the new chain.
Recommendations
Short term, add chainID to the signature schema to prevent post-deployment forks from affecting this permit.
Long term, identify and document the risks associated with having forks of multiple chains, and develop related mitigation strategies.

I am afraid I am not entirely following and I need some more explanation. Is this issue only about Ethereum 1.0 -> Ethereum 2.0 upgrade or about Ethereum 1.0 chain forks as well?
Once ready, Ethereum 1.0 will merge with Ethereum 2.0 Beacon Chain, becoming its own shard so the state of the contract will be maintained.  Eve can not replay permit transactions because Ethereum 2.0 will expect a higher nonce in the Permit structure.
Thinking about two different chains with two different IDs, Eve can not replay permit transactions because of a different chain ID in DOMAIN_SEPARATOR.
In the case of forks at the same chain, say Ethereum 1.0 chain forks, transactions can be replayed between forks but that is always true, not only in case of ERC20WithPermit.

I used eth 1 > eth 2 as an example, but the exploit works with any fork on eth 1 that is done after the deployment of UnderwriterToken.
Put in another words, after the fork, DOMAIN_SEPARATOR will be the same in both forks, because it is evaluated at deployment only.

In the case of forks at the same chain, say Ethereum 1.0 chain forks, transactions can be replayed between forks but that is always true, not only in case of ERC20WithPermit, and thus allows replays.

chainId was introduced to prevent this (https://github.com/ethereum/EIPs/blob/master/EIPS/eip-155.md); the encoding of the transaction contains now the chainID and prevent the replay.

For this issue to happen, eth 1 fork needs to have another chain ID, correct? I think the best way to address it could be to validate the current chain ID against the cached one and if they do not match, build a new domain separator and use it in permit.


CI failure: fail to Download action repository 'actions/checkout@v3

Set title to be in the format CI: .
CI failure: fail to download action repository 'actions/checkout@v3
Copy-paste the output the test failure.

Upload the zip file generated from that test failure.
Copy-paste the link of the CI build where that test failure has happen.
https://github.com/kubean-io/kubean/actions/runs/6019615444/job/16330552280?pr=944
Include any output from logs that you think may be relevant (to ease GitHub searches).
actions/checkout has been upgraded recently

Thanks for your reporting the issue, after debugging, it seemed like network connection issue during the runner and gitlab.
Also we had no strong reason to upgrade plugin to v4. Will close the issue firstly.


更新了flutter后footer出现错误：SliverGeometry has a paintOffset that exceeds the remainingPaintExtent from the constraints.

更新了flutter后footer出现错误：SliverGeometry has a paintOffset that exceeds the remainingPaintExtent from the constraints.
════════ Exception caught by rendering library ═════════════════════════════════
The following assertion was thrown during performLayout():
SliverGeometry has a paintOffset that exceeds the remainingPaintExtent from the constraints.
The render object whose geometry violates the constraints is the following: RenderSliverLoading#36d29 relayoutBoundary=up1 NEEDS-LAYOUT NEEDS-PAINT NEEDS-COMPOSITING-BITS-UPDATE
The remainingPaintExtent is 237.0, but the paintOrigin + paintExtent is 292.0.
The paintOrigin and paintExtent must cause the child sliver to paint within the viewport, and so cannot exceed the remainingPaintExtent.
The relevant error-causing widget was
CustomFooter
lib/forum_main.dart:39
When the exception was thrown, this was the stack
#0      RenderSliver.debugAssertDoesMeetConstraints.
package:flutter/…/rendering/sliver.dart:1215
#1      RenderSliver.debugAssertDoesMeetConstraints
package:flutter/…/rendering/sliver.dart:1229
#2      RenderObject.layout.
package:flutter/…/rendering/object.dart:1770
#3      RenderObject.layout
package:flutter/…/rendering/object.dart:1772
#4      RenderViewportBase.layoutChildSequence
package:flutter/…/rendering/viewport.dart:451
...
The following RenderObject was being processed when the exception was fired: RenderSliverLoading#36d29 relayoutBoundary=up1 NEEDS-LAYOUT NEEDS-PAINT NEEDS-COMPOSITING-BITS-UPDATE
RenderObject: RenderSliverLoading#36d29 relayoutBoundary=up1 NEEDS-LAYOUT NEEDS-PAINT NEEDS-COMPOSITING-BITS-UPDATE
parentData: paintOffset=Offset(0.0, 0.0) (can use size)
constraints: SliverConstraints(AxisDirection.down, GrowthDirection.forward, ScrollDirection.idle, scrollOffset: 0.0, remainingPaintExtent: 237.0, crossAxisExtent: 375.0, crossAxisDirection: AxisDirection.right, viewportMainAxisExtent: 667.0, remainingCacheExtent: 487.0 cacheOrigin: 0.0 )
geometry: SliverGeometry(scrollExtent: 0.0, paintExtent: 55.0, paintOrigin: 237.0, maxPaintExtent: 55.0, hasVisualOverflow: true, cacheExtent: 55.0)
scrollExtent: 0.0
paintExtent: 55.0
paintOrigin: 237.0
maxPaintExtent: 55.0
hasVisualOverflow: true
cacheExtent: 55.0
child: _RenderLayoutBuilder#47e10 relayoutBoundary=up2 NEEDS-PAINT NEEDS-COMPOSITING-BITS-UPDATE
parentData: paintOffset=Offset(0.0, -0.0) (can use size)
constraints: BoxConstraints(w=375.0, 0.0<=h<=Infinity)
size: Size(375.0, 55.0)
child: RenderSemanticsGestureHandler#d6f37 relayoutBoundary=up3 NEEDS-PAINT NEEDS-COMPOSITING-BITS-UPDATE
parentData: offset=Offset(0.0, 0.0) (can use size)
constraints: BoxConstraints(w=375.0, 0.0<=h<=Infinity)
size: Size(375.0, 55.0)
gestures: tap
child: RenderPointerListener#3324b relayoutBoundary=up4 NEEDS-PAINT NEEDS-COMPOSITING-BITS-UPDATE
parentData:  (can use size)
constraints: BoxConstraints(w=375.0, 0.0<=h<=Infinity)
size: Size(375.0, 55.0)
behavior: opaque
listeners: down
child: RenderConstrainedBox#ad0f9 relayoutBoundary=up5 NEEDS-PAINT NEEDS-COMPOSITING-BITS-UPDATE
parentData:  (can use size)
constraints: BoxConstraints(w=375.0, 0.0<=h<=Infinity)
size: Size(375.0, 55.0)
additionalConstraints: BoxConstraints(0.0<=w<=Infinity, h=55.0)
════════════════════════════════════════════════════════════════════════════════

me too

The same as yours.

You can try warp smart refresher with a exactly height container if your tile is not dynamic height.
Container(
        height: 100.0 * _dataSource.length,
        child: SmartRefresher(
          ......

It will be a temporary solution.

I have the same issue.

Same issue.

已修复

Still having this issue


add engine options for refresh interval

This is part of the solution to #1328. This change supports engine refresh with the following 3 options. They can be used to control how fast a node's state will change.
--engine-refresh-min-interval "30s"					set engine refresh minimum interval
--engine-refresh-max-interval "60s"					set engine refresh maximum interval
--engine-refresh-retry "3"						set engine refresh retry count on failure
Signed-off-by: Dong Chen<EMAIL_ADDRESS>

Design LGTM
@dong Can you please squash the last two commits? Thanks!

LGTM

I'd love to merge this, but our CI seems to fail.
@abronan Any idea why? I just merged your PR that was meant to fix the CI.

@aluzzardi looking at the logs docker ps --before seems to be a legitimate failure. reschedule with image affinity seems to be legitimate too: image busyboxabcde seems to be inaccessible.

Tested locally (will open a separate issue for unrelated CI failures, tests needs to be updated supposedly because of changes in docker master).
LGTM


Respect JULIA_PROJECT environment variable if set

I am using the python package juliacall and am surprised to find that it ignores JULIA_PROJECT environment variable.
Julia documentation about JULIA_PROJECT.
It would be great if this standard variable is respected. Currently juliacall opens a new julia environment pyjuliapkg

It seems related to https://github.com/JuliaPy/PyJuliaPkg in that a workaround could be to set PYTHON_JULIAPKG_PROJECT

It seems there is not a single workaround to start JuliaCall in a predefined environment.
Respecting the environment variable JULIA_PROJECT could be a good way to add this feature.

PythonCall already sets up a pseudo juliacall package when plainly run from julia.
Maybe this already existing mechanism could be reused to start juliacall in an existing environment.

Ignoring JULIA_PROJECT is intended. You can set PYTHON_JULIAPKG_PROJECT and PYTHON_JULIAPKG_OFFLINE=yes to get the behaviour you want, I think?

Thank you for reminding me that both variables need to be set. For me, coming from julia, it is very unintuitive to set two environment variables in order to get an Julia environment to work.
My tests where successful, it worked. Thank you.

What about translating the JULIA_PROJECT environment variable automatically to those two PYTHON_JULIAPKG environment variables?


Suggest state or country for typed address

People type into search box often an address.
We could detect this with Google Geocoder in JavaScript.
In case the address is detected, and we have no results, then we can show coordinate system for the country (state for USA or Germany) from detected address and suggest "coordinates on a map" at given location.

Done! Thanks @daliborjanak


feat(python/adbc_driver_snowflake): package the Snowflake driver

Fixes #629.

 Otherwise I may disable the check for the Go-based drivers

Ah, and it looks like the snowflake driver can't be cross-compiled because it uses arrow 11, and there was a bug that was only fixed in arrow 12.

We can pass arbitrary options to the compiler and linker in the go compile command when we build the shared library. So if you know the flags to pass to GCC to hide the symbols I can add them to command and in theory it should work....

And for snowflake, once v12 is released I'll upgrade the snowflake lib to use it

@lidavidm What symbols are getting added that we want to hide?

We can pass arbitrary options to the compiler and linker in the go compile command when we build the shared library. So if you know the flags to pass to GCC to hide the symbols I can add them to command and in theory it should work....

We should pass the linker script then that the other drivers use.
 Not a big deal necessarily, but it fails the check.

https://github.com/apache/arrow-adbc/blob/main/c/symbols.map
https://github.com/apache/arrow-adbc/blob/b965f64886026ed17f5e60f96b819af9472fe484/c/cmake_modules/AdbcDefines.cmake#L55

@lidavidm #640 updates the cmake config to hide the symbols for the Go libs :smile:

@zeroshade seems even with noasm it doesn't work:
Error: /Users/runner/go/pkg/mod/github.com/apache/arrow/go/v11@v11.0.0/arrow/compute/internal/kernels/basic_arithmetic_noasm.go:27:9: undefined: getGoArithmeticOpFloatingSameType
Error: /Users/runner/go/pkg/mod/github.com/apache/arrow/go/v11@v11.0.0/arrow/compute/internal/kernels/basic_arithmetic_noasm.go:35:9: undefined: getGoArithmeticFixedIntOut

Guessing the upgrade will take a while? I may punt on arm64 for now

Not packaged for macOS/AArch64.


Adding Accept-Language on down stream calls

I'm trying to use this sdk for  production service. I would love to be able to pass error messages from the sdk to the user in cases that in makes sense. But that is only possible if they are localized to the language requested in my accept language header. So I want to be able to do something similar how .Authorizer. I want to be able to either do a  client.CustomHeaderFunc = func(headers){ //add my headers} or client.AcceptLanguageValue = myServiceRequest.Headers.Get("Accept-Language").
I'd be willing to help write the code if someone could point me in the right direction.

Hello @JackQuincy !
What you can do is use the preparer, sender and responder for each operation and add the Accept-Language header after preparing the request. Lets say you want to create a resource group, the code would look like this:
	resourceGroupParameters := resources.Group{
	// Location: &location,
	}

	req, err := groupClient.CreateOrUpdatePreparer(groupName, resourceGroupParameters)
	if err != nil {
		fmt.Println(err)
	}
	req.Header.Add("Accept-Language", "es-es")

	resp, err := groupClient.CreateOrUpdateSender(req)
	if err != nil {
		fmt.Println(err)
	}
	_, err = groupClient.CreateOrUpdateResponder(resp)
	if err != nil {
		fmt.Println(err)
	}

Because location parameter is not included (but it is a required parameter), this code fails. But because of the Accept-Language header, the error looks like this:
autorest/azure: Service returned an error. Status=400 Code="LocationRequired" Message="Se necesita la propiedad de ubicación de esta definición."

Thanks, I think this should work.

I wrote the code for this and there was alot of copy and pasting needed to do this. Am I doing it wrong in  https://github.com/Azure/acs-engine/issues/808

You are not doing it wrong, but I have to agree code looks cumbersome. I we were to  add this kind of functionality to the clients, I think the best place to add this is in go-autorest. Thoughts @marstr  @jhendrixMSFT ?

Ok, yes, there is a better way to do this :)
import (
	"github.com/Azure/go-autorest/autorest"
)

func WithAcceptLanguageHeader(language string) autorest.PrepareDecorator {
	return autorest.WithHeader("Accept-Language", language)
}

func main() {
	groupClient.ManagementClient.Client.RequestInspector = WithAcceptLanguageHeader("es-es")
	resourceGroupParameters := resources.Group{
		Location: to.StringPtr("nonexisitinglocation"),
	}

	_, err := groupClient.CreateOrUpdate(groupName, resourceGroupParameters)
	if err != nil {
		fmt.Println(err)
	}
}

Again the error is in Spanish...
resources.GroupsClient#CreateOrUpdate: Failure responding to request: StatusCode=400 -- Original Error: autorest/azure: Service returned an error. Status=400 Code="LocationNotAvailableForResourceGroup" Message="La ubicación proporcionada, 'nonexisitinglocation', no está disponible para el grupo de recursos. La lista de las regiones disponibles es 'centralus,eastasia,southeastasia,eastus,eastus2,westus,westus2,northcentralus,so uthcentralus,westcentralus,northeurope,westeurope,japaneast,japanwest,brazilsouth,australiasoutheast,australiaeast,westindia,southindia,centralindia,canadacentral,canadaeast,uksouth,ukwest,koreacentral,koreasouth'.

Apparently I forgot to hit comment. So this is better but it is limited to a single prepare decorator as I can't nest prepare decorators. Is there a reason why not?

A PrepareDecorator can do more than just adding a single header if that is what you mean. Take a look at this example.

that last example worked. It would of been easier if we had a function like
// Nest returns a PrepareDecorator that nests the prepare decorators together.
func Nest(pds ...PrepareDecorator) PrepareDecorator { 	return func(p Preparer) Preparer { 		for _, pd := range pds { 			p = pd(p) 		} 		return p 	} }

Howdy folks, sorry I haven't weighed in earlier, I know this issue is closed.
I wanted to point out quickly that part of why this hasn't come up before is that just all of the functions that take a PreparerDecorator already take a variadic number of them. The notable exception to this seems to be the autorest.Client model which has one PreparerDecorator. This seems odd to me, my gut tells me it should be a Preparer, but I'm willing to look the other way a bit.
One thing I will mention here (as well as on the PR that is open) is that if we do it, we should make sure to extend this across to ResponderDecorators as well.


@validate_call doesn't catch wrong type being passed to parametrized generic method; generic functions also have the same issue

Initial Checks

[X] I confirm that I'm using Pydantic V2

Description
validate_call should catch wrong types being passed to any function/method; however, it breaks when used with parametrized generic methods.
A similar issue occurs when generic functions have incorrect return type.
Example Code
from typing import TypeVar, Generic

from pydantic import BaseModel, validate_call

T = TypeVar("T")

class MyGModel(BaseModel, Generic[T]):
    @validate_call
    def my_generic_method(self, arg: T) -> None:
        return

# Should fail because 1 is not str
MyGModel[str]().my_generic_method(1)

@validate_call(validate_return=True)
def my_func(arg: T) -> T:
    return 1

# Should fail because "5" is str, but 1 is int
my_func("5")

Python, Pydantic & OS Version
pydantic version: 2.4.2
        pydantic-core version: 2.10.1
          pydantic-core build: profile=release pgo=true
                 install path: /home/can/.cache/pypoetry/virtualenvs/chainspect-uudSkfMt-py3.11/lib/python3.11/site-packages/pydantic
               python version: 3.11.4 (main, Jun 19 2023, 07:09:29) [GCC 13.1.1 20230429]
                     platform: Linux-6.5.6-zen2-1-zen-x86_64-with-glibc2.38
             related packages: mypy-1.5.1 typing_extensions-4.8.0

@caniko,
Thanks for reporting this. It does seem to be a bug 🐛.

Going to move this to a feature-request instead - though I think it's one that should be relatively high on our list 😄.

Hi @sydney-runkle, since the https://github.com/pydantic/pydantic/issues/7928 has been closed, would it make sense to add this issue to a milestone, since it seems to be your new approach to issues?

@AmailP,
This isn't a super high priority issue at the moment, so I don't think we'll add it to the 2.7 milestone. If there's more community support, or if someone wants to take this on, we can certainly move up the timeline!

A good example of this lack of support: https://github.com/pydantic/pydantic/issues/9536

I'm going to add this to v2.9 - this is something I'd like to work on, though it will take a back seat compared to performance concerns in the 2.9 sprint.

Damn, I'm having a problem with the weather application. each day we receive 1 day less.
The application works great but, for some reason (maybe gismeteo noticed the increase in the query I'm using and shut down the service, maybe they've made an update that makes the service obsolete) the forecasts returned contain fewer and fewer days.)
I think there must be a way of making the query by forcing these but I haven't found it (I'm still looking).


Update 0092-premine-error-correction.md

Removing Foundation mention.

What is confirmed is that if the donation wallet does not meet the target then the Foundation will transfer enough to meet the target from the IOT Operations fund managed by the Foundation.
Topping up the fund will not come direct from the Foundation. But a wallet under the control of the Foundation.

Is this still pending @capjbadger007 ?

Is this still pending @capjbadger007 ?

Oh, yes, I think so. I'm not sure how to push it forward.

Closing on behalf of author.


Ability to specify PowerPC VLE flag value to be used with dynamically generated code

Is your feature request related to a problem? Please describe.
I'm using the GUI emulator to emulate a PowerPC:BE:64 binary. At some point a function is copied from flash to ram and run from there. The problem is that the new ram code is considered non vle ("set register value" does not work) and not properly disassembled (as seen on the dynamic window). Additionally the "decompile" window is not populated while this dynamically generated code is running.
Describe the solution you'd like
The vle value should be kept when "jumping" from static to dynamic code and the decompile window should refresh and "capture" the new assembly.
Describe alternatives you've considered
Alternatively the set register value menu could work on the dinamic window.

There is a dedicated VLE disassembly action.  Alternatively you can set the VLE context over a memory region.  The register value editor can be used to do this.  The API can also be used to set the context programmatically.

To be clear, what the Dynamic Listing displays is not necessarily the same as what the Emulator is going to decode. That said, if they disagree, that is a point of concern, since I'd like the Listing to show what the Emulator will do.
To see what the Emulator is actually decoding, turn on the DebuggerPcodeStepperPlugin. (Use File → Configure → Configure All Plugins — in the top right.) This should add a new pane. If it's not obvious where it is, use Window → Debugger → Pcode Stepper. That pane will have "Emulate p-code tick" buttons instead of "Step Instruction" buttons. Step one p-code tick forward to have the Emulator decode an instruction. The Stepper panel should display the decoded instruction right above the table of ops. Check whether that's the VLE instruction or non-VLE. If VLE, then the Emulator is doing as you expected, and you can try manually disassembling.
In the Dynamic Listing, right-click the first instruction of the copied function and select Disassemble as .... One of the options ought to be the VLE instructions. Again, I concur that it should just agree with the Emulator, but at least that'll get the Listing displaying the expected instruction set.
The Decompiler is intentionally left bound only to the Program database. There have been brief discussions about binding it to the Dynamic Listing (i.e., the Trace database), but the underlying Trace database does not completely implement all of the interfaces required to support decompilation. We had aimed for this as we were first developing it, but it proved too costly compared to alternatives. Instead, we allow the user to manually (deliberately) capture dynamic data back into the Program database, which can then be decompiled (not to mention analyzed, marked up, and shared) as usual. To do this, select the portion in the Dynamic Listing you'd like to capture. Then, in the menus, select Debugger → Copy Into Current Program.

To be clear, what the Dynamic Listing displays is not necessarily the same as what the Emulator is going to decode. That said, if they disagree, that is a point of concern, since I'd like the Listing to show what the Emulator will do.

It appears they do disagree (using auto-disassembly). After enabling the PCode Stepper it seems that the emulator is in fact using VLE but the dinamic listing shows non VLE opcodes.

In the Dynamic Listing, right-click the first instruction of the copied function and select Disassemble as .... One of the options ought to be the VLE instructions. Again, I concur that it should just agree with the Emulator, but at least that'll get the Listing displaying the expected instruction set.
Doesn't seem to work, the dinamic listing remains the same (un-disassembled/assembled) using "disassemble" or "disassemble as".

The Decompiler is intentionally left bound only to the Program database. There have been brief discussions about binding it to the Dynamic Listing (i.e., the Trace database), but the underlying Trace database does not completely implement all of the interfaces required to support decompilation. We had aimed for this as we were first developing it, but it proved too costly compared to alternatives. Instead, we allow the user to manually (deliberately) capture dynamic data back into the Program database, which can then be decompiled (not to mention analyzed, marked up, and shared) as usual. To do this, select the portion in the Dynamic Listing you'd like to capture. Then, in the menus, select Debugger → Copy Into Current Program.
I understand the reasoning and the workaround for static analysis , but it would be nice to follow a decompiled listing while stepping the emulator.

I understand the reasoning and the workaround for static analysis , but it would be nice to follow a decompiled listing while stepping the emulator.

I'll follow-up a bit: Once the bytes are copied in, the static listing should still follow the dynamic one, and so you'll have the decompiler following along while you step through the copied function, too.


Authorization Points (i.e. authorization on at-the-point-of-authorization basis) as an improvement on current methodologies

I have a proposal for the Identity team to include a feature, especially as an optional feature and upgrade, that would enable authorizing based on at-the-point-of-authorization basis, for example...
[Authorize(AuthorizationPointId = "UniqueIdOfThisAuthorizationPoint")]//The value of the unique authorization point ID could be a GUID string or something familiar and human-readable, as chosen by the developer.
public ActionResult EditBlogPost()
{
    ...
}
...instead of just based on hard-coding the names of roles, etc., as it's being currently done, for example...
[Authorize(Roles = "Admin")]
public ActionResult EditBlogPost()
{
    ...
}
The currently used method, i.e. based on hard-coding names of roles, etc., is not scalable and quite a bad practice, because when role names happen to get changed in the lifetime of the solution, it can become hard to reflect the changes in code.
Now, with this request or solution I am proposing, authorization point IDs should be used as an optional feature. Every identity entity (i.e. roles, claims, users, etc.) that should be able to access code or resource being guarded must be enrolled in the said authorization point. This enrollment can be eased if the Identity team can provide a Visual Studio integration or solution for that (similar to how web pages are already prepared to register users, etc.), because, for example, if a developer decides to use GUID strings as their authorization IDs, it can be hard to bear in mind the roles and users that can have access through said authorization IDs. But if there can be a Visual Studio integration such that, for example, on mouse hovering over the Authorize attribute, enlisted roles and users can pop up in some way similar to how IntelliSense does it.
I have used this methodology in my own private coding and it works very fine. I didn't implement mine using the Authorize attribute though. Anybody who have been faced with the inflexibility of Identity in the area of renaming roles and some other tasks that could make things flexible, can testify to how Identity can quickly become unhelpful beyond mere authorization.
I plead with the Identity team to REALLY consider this and make it a feature in Identity.

@pranavkm @HaoK Please, this is worth your attention, unless I'm not knowledgeable enough about if Identity already has a scalable and viable solution to this.

The great part of this proposal is that authentication point IDs scale with the solution since they don't have to be changed, only the roles and users associated with it have to be re-enlisted.

It's already supported and known as policy-based authorization: https://docs.microsoft.com/en-us/aspnet/core/security/authorization/policies.

@PinpointTownes Thank you.
Policy-based authentication does not entirely tackle all of what I'm asking for. How about having to hard-code role names? And besides, what I am asking for qualifies as an entirely new feature if critically looked at.@PinpointTownes Thank you.
Policy-based authentication does not entirely tackle all of what I'm asking for. How about having to hard-code role names? And besides, what I am asking for qualifies as an entirely new feature if critically looked at.

@PinpointTownes Thank you.
Policy-based authentication does not entirely tackle all of what I'm asking for. How about having to hard-code role names? And besides, what I am asking for qualifies as an entirely new feature if critically looked at.@PinpointTownes Thank you.
Policy-based authentication does not entirely tackle all of what I'm asking for. How about having to hard-code role names? And besides, what I am asking for qualifies as an entirely new feature if critically looked at.

@PinpointTownes Thank you.
Policy-based authentication does not entirely tackle all of what I'm asking for. How about having to hard-code role names? And besides, what I am asking for qualifies as an entirely new feature if critically looked at.

I'm with @PinpointTownes on this, you can do this with policies as of now, you're just replacing a policy name with another type of ID. Policies mean you don't hard code role names.
Roles based authorization via attributes is there for backwards compatibility.

@blowdart Thanks.
But when you create policies, somewhere along the way you hard-code role names. And that's still a problem.
For now, what I personally do is, in a database, I assign a GUID as ID to every role name, so that when I change role names their reference will still be maintained. Then, I enlist the IDs of roles under IDs of Authentication Points, which I then use instead of policies. I don't get to use the full capacity of Identity in for real, mainly because of having to hard-code role names, even though hard-coding policy names isn't a problem. This seems like a crude approach (or not) but it works and is extremely powerful.
So, because this approach can actually be tiresome, it will be great if other people and/or the Identity can just take a closer look at it and implement it or something more refined. Having to hard-code role names is enough reason for a change, even though Identity seemingly provides a way to rename roles, but which does not still prevent hard-coding of role names.

No you don't. You can quite happily get the current roles from a database.
You're hung up on roles. You don't have to use roles at all, we'd rather you didn't, we'd rather you look at claims, something the user is, and then turn those into permissions within the policy handler, which is basically what you want for your hard coded guid, you can do that now if you want to write the code.

@blowdart Thanks, again.
Actually, I now get it more clearly that claims and policies solve the problem if used cleverly. They make the problem of hard-coding gone too. In the documentation, there should have been more on claims and policies, but there's very little. Roles can essentially be done away with because claims can actually replace the use of roles, as you rightly said. This should also be emphasized in the documentation.

@blowdart
Although most claim values are essentially permanent and don't need to change, e.g. setting an age limit, etc. But I am still concerned about having to hard-code something that should be changeable as claim values.
I'm not yet satisfied but I can/would improvise on top of what claims and policies now provide.

You don't have to hard code anything at all. What comparisons you do inside a policy could come from XML, SQL, MongoDB, JSON, whatever, you just need to provide the parsing code. In fact we have people building products on that flexibility, https://policyserver.io/ is one such product.

Closing as this isn’t something we’d want to persue

OK. Great. That's pretty much what's to be done, getting data from other sources.


FLIP for publish and claim for capabilities

Adds a new proposal for a pair of API functions: publish and claim that are designed to address the capability bootstrapping use case detailed here https://github.com/onflow/cadence/issues/1951

For contributor use:

[X] Targeted PR against master branch
[X] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[X] Updated relevant documentation
[X] Re-reviewed Files changed in the Github PR explorer
[X] Added appropriate labels

cc @bjartek @bluesign as you were involved in the discussion on the original FLIP

Maybe allowing claim to both accounts can be good. ( if I publish to wrong address etc )
Also will this dictionary be available to user ? Some kind of seeing what I published, when I published can be good. If I published you something 1 month ago, if you didn't claim I want to be able to clean probably.

Also fun claim<T: Any>(_ name: String, provider: Address): T? is there a reason this is not something like: getAccount(provider).claim<T:Any>(_ name: String)
I think it will be more familiar if we somehow use getAccount.
PS: unless we will have some kind of listing for potential things I can claim. But then we are becoming full inbox.

Also fun claim<T: Any>(_ name: String, provider: Address): T? is there a reason this is not something like: getAccount(provider).claim<T:Any>(_ name: String)
I think it will be more familiar if we somehow use getAccount.
PS: unless we will have some kind of listing for potential things I can claim. But then we are becoming full inbox.

At the moment the account calling the claim function has to be the recipient account: recipient.claim<T>(name, provider). If the provider is the account on which the claim function is called, then we have no argument that tells us which account is actually claiming the object.

At the moment the account calling the claim function has to be the recipient account: recipient.claim(name, provider). If the provider is the account on which the claim function is called, then we have no argument that tells us which account is actually claiming the object.

Thanks, makes sense

Would it make sense to have a third function to revoke/cancel a claimable item as well? Or would the assumption be that you would instead just destroy the underlying capability/resource being claimed which would mean it can't happen anyway

Thanks for the quick comments on this! Based on the discussion so far, it seems like we need two more additional pieces of functionality here:

The ability to revoke a published object. This would only be possible if the calling account was the one who originally published it (obviously) and would return the resource/capability/value in question, while removing it from the publishing dictionary.

More information about what is available to be claimed and by whom. In the interest of not becoming a full inbox, as @bluesign said, I am leaning towards having this information be mostly off-chain, perhaps using events like @austinkline suggested. We could emit an event when something is published containing its name and who it is for, an event when it is claimed, and an event if it is unpublished. This way users who can choose to submit transactions to claim objects based on these events, but the publishing dictionary is not inspectable on-chain at will, as this would break the abstraction that the publish/claim API is intended to provide.

In the events discussion, problem here is: this is privileged function ( claim ), so we cannot use it as a building block, enrich with contracts, etc. So events are for sure important, but also I think some kind of on-chain query would be also nice. At least some list of addresses, which I can claim something ( like a notification )

I added an unpublish function that takes the name of the published value and removes it and returns it.

I'm very supportive of this FLIP! It's a major improvement over the identity object proposal, and it doesn't encourage the msg.sender pattern. However, I think it introduces a major issue with spam and other abuse.
Spam and Abuse
In capability-based security, a lot of the security comes from the fact that everyone is disconnected from each other until they explicitly consent to connect (and that connection can be revoked.) This FLIP proposes to change that. Now everyone has a direct, irrevocable connection to everyone else. Granted, there are some protections: the Provider is paying all the storage costs for what they are sharing.
However, relying on storage costs alone to prevent spam and abuse will break as soon as the incentive for abuse > storage costs. For instance, imagine a motivated and coordinated harassment attack, where the Recipient keeps getting notifications where the string name is used to send threatening and abusive messages. Thus, there needs to be an easy way to revoke this connection between accounts.
Solutions
An easy solution would be to add a block method to the AuthAccount, which takes a sender address. However, that's still putting the burden on the user to actively block, rather than allowing them to affirmatively consent to interaction with specific other accounts.
I wonder, since this FLIP is supposed to only be about solving the bootstrap problem, if the publish/claim API should be much more limited. Specifically, the Recipient could publish only one capability per Provider. And that capability would be of a particular type: a private inbox. In this case, there's no need for a name that can be used to transmit abusive messages from the general public.
Here's how I imagine Dete's example use case would work:

Dete wants to share the pause capability with Bjarte. Bjarte, knowing that Dete is unlikely to spam or abuse him, creates an inbox capability specifically for Dete that allows Dete to send Bjarte anything with no rate limits. Bjarte publishes this for Dete, and Dete claims it. Now Bjarte can receive capabilities and resources from Dete without having to actively claim. We could imagine in the future that Bjarte's inbox actually decides how the received things are named and stored in Bjarte's account, thus giving Dete an attenuated authority to Bjarte's storage, restricted to the things Dete has sent as well as other rules (like subfolders or resources within collections).

As another use case, let's imagine that rather than Dete, the sender is someone that Bjarte doesn't trust much:

Bjarte would want to only allow the minimum access that is needed. He wants the ability to revoke, of course, but also perhaps it's a one time inbox so access is automatically cut off without having to send another transaction to revoke.

Complications and other thoughts

Since the boundary between a Provider and a Recipient is not asynchronous, if a Provider creates a transaction that starts executing the Recipient's inbox rules, there's the possibility for reentrancy and other malicious behavior by the Recipient. Requiring a claim in a later transaction is actually nicely asynchronous.
As @janezpodhostnik has pointed out, the inbox model, which is often used in the capability world, doesn't work very well if the recipient pays for storage, due to the ability to spam. Possible solution: the recipient needs to be able to specify rules that run prior to storing anything on their side and prior to any notifications.

At this point, I think we definitely need to solve the spam/abuse problem, and I would love to find a way to do that using the private inbox pattern, since that is the traditional capability pattern for this. However, the above complications might make that infeasible. Still, any step towards a private inbox model, especially allowing for attenuation (rules about who can send what when), might be a step in the right direction.

@katelynsills thank you for the detailed comment! I hadn't considered the potential for spam and abuse when designing the API, so I appreciate that you pointed it out here. Based on my understanding of your analysis (and please correct me if I am wrong here!), the primary issue with the API currently is that it allows a Provider to send something to any Recipient, without the Recipient's explicit consent.
One potential option would be to reverse the responsibility relationship for who initiates the connection: instead of publish and claim, where the Provider initiates by publishing a value and the Recipient chooses to claim it later, we could perhaps have something like request and provide/fulfill where a Recipient requests a value of a specific type from a Provider, and the Provider later fulfills that request by sending the value to the Recipient. However this may still have the potential for spam, just in the other direction, with a Recipient spamming a provider with spurious requests.
Another solution to this would be the inverse of the block method you described; a permit or allow method that a potential Recipient can call to add a potential Provider to their allowlist. This way a Provider can only publish a value to a Recipient that has explicitly opted to allow them to do so, and the Recipient can revoke this permission at any time via a method that would remove the Provider from this allowlist. We could extend this further by allowing the Recipient to specify a type argument that specifies exactly what types of values they wish to receive from the Provider they are allowlisting, and potentially even an argument specifying how many values they wish to receive before automatically closing the connection.
This seems like a limited version of the private inbox paradigm you are suggesting, that also addresses the additional complications you mentioned: because the Recipient must still explicitly claim things that the Provider publishes to them, it maintains the asynchronous nature of the connection and also requires the Provider to pay for storage until such time as the Recipient consents to receive the value they are being sent.
Let me know your thoughts on this! It's very possible I have missed some more cases here.

@bluesign

Maybe allowing claim to both accounts (sender and receiver) can be good.

Do you mean that the sender is able to claim on behalf of the receiver, so they could unpublish the capability, e.g. to clean up?

Some kind of seeing what I published, when I published can be good.

Agreed! Some form of on-chain introspection would be great. We already have it for some on-chain data (e.g. storage iteration) and are currently adding it for other data (e.g. account keys) where it is missing.

Also fun claim<T: Any>(_ name: String, provider: Address): T? is there a reason this is not something like: getAccount(provider).claim<T:Any>(_ name: String)
I think it will be more familiar if we somehow use getAccount.

The claim function needs to be defined on AuthAccount, not PublicAccount, so that the claim function can verify the identity. If the claim function would be defined on PublicAccount, anyone could claim the capability, as anyone can call getAccount to get the PublicAccount.

Do you mean that the sender is able to claim on behalf of the receiver, so they could unpublish the capability, e.g. to clean up?

yeah but @dsainati1 already added unpublish, though I was just gonna comment on that I think recipient should be in that too. ( if I will send 100 people FLOAT for example, I cannot name them all unique probably )

@katelynsills
Good point! At first I assumed that such a system, given that it is a mailbox, would be similar to e.g. snail and electronic mail, which are opt-in by default. However, given that this FLIP proposes a system for a very specific and limited purpose, bootstrapping capabilities, requiring explicit permission from the receiver for the sender to publish something seems reasonable 👍

@bluesign

Do you mean that the sender is able to claim on behalf of the receiver, so they could unpublish the capability, e.g. to clean up?

yeah but @dsainati1 already added unpublish, though I was just gonna comment on that I think recipient should be in that too. ( if I will send 100 people FLOAT for example, I cannot name them all unique probably )

Ah, I didn't saw that yet. An unpublish function seems functionally equivalent to allowing claiming by the sender, but it seems slightly more explicit.

if I will send 100 people FLOAT for example, I cannot name them all unique probably

I don't think this is the intended use case for this feature; if you want to send people tokens, for example, we'd much rather encourage you to use the existing Vault capabilities. By requiring people to give unique names to values they send through this API we can encourage it to be limited to distinct, personal exchanges rather than being a venue for broadcasting many identical values to many people.

@dsainati1, I really like the permit idea. In a way, it's effectively solving the time-window problem that co-signed transactions had while keeping the same security. With permit, both accounts still consent to the connection (the Recipient through permit, the Provider through publish) but can now do so asynchronously.
Regarding attenuation, you're right that we could add opt-in restrictions as part of the API (specify the type, number of messages etc.). But, I think we don't want to hard-code it as part of the API because that's not encouraging people to create their own capabilities with their own rules. Ideally, if I want a new kind of rule, I shouldn't need to request a change to the API that everyone uses; I can just write the code that controls my inbox.
Given that the spam issue is solved with permit, I think it's fine to move forward without tackling attenuation, but I think capability-based attenuation might be a good future goal.

However, given that this FLIP proposes a system for a very specific and limited purpose, bootstrapping capabilities...

Are we planning to limit this to capabilities ? If so maybe we can merge this with Capabilities FLIP.

Are we planning to limit this to capabilities ? If so maybe we can merge this with Capabilities FLIP.

I still think this is an open question; the API is perfectly functional for values of any type, so if we choose to restrict it it would be for the express purpose of limiting the use cases, not because it would not work for sending non-capability values.
Either way though, I don't think it makes sense to merge the FLIPs. This API is related-to but separate-from the Capability Controllers FLIP because it's designed to work independently of whatever changes are decided upon there; regardless of how Capabilities may change as a result of that, this should still be able to send them between accounts with this API. Also the Capability Controllers would be a breaking change (and thus need to wait for Stable Cadence), while this would not, so keeping these separate would allow us to get this feature to users faster.

Sure but if we go permit path. We are just adding something which we can achieve with a contract already.
Considering below flow:
0x2:  permit 0x1 to publish me the resource
0x1: publish the resource to 0x2
0x2: claim from 0x1 the resource
this is already possible with:
0x2: set up account, put some resourceReceiver resource with function saveCapability(Capability)
0x2: set whitelist address: [0x1]
0x1: call saveCapability(Capability) with your capability (cap)  ( 0x2: check if cap.address is in whitelist  )
All power of this API is removing need for setup.

I have made a couple changes to the proposal:

These functions are now grouped into an Inbox nested struct on the Account type to keep them organized

I've added an allowlist field to inbox that tracks the list of Addresses that are permitted to publish to that account. An account can add to it using permit and remove from it using unpermit. A Provider account can only publish to a Recipient account if the Recipient's allowlist contains the Provider's Address. In order to allow users to check whether they are able to send values to a Recipient, the allowlist (and only the allowlist) is readable on PublicAccount objects.

Few last thoughts:
** Capability or Any **
I think this system can solve more than "capability bootstrap".  As long as we leave signature as Any it will be used as such creative ways. So decision to limit capabilities or not, changes all dynamics here.
** Practical Usage **
Let's confess, every transaction in any dapp now will have one more prepend line ( like initialization of collection etc ), which will be something like: acct.Inbox.permit(Address(DAPP_ADDRES)) running. So there is no single chance you can disallow any dapp you are using.
Spam/Abuse case
I think permit here is overprotective. Maybe I am too old fashioned, but I think we have 2 pieces at work here: Publishing the capability ( or resource ) and Notifying the user that there is something waiting for them.
As long as I don't get any notification, someone sharing me something somewhere is no base for Spam/Abuse. Technically in our system what we call inbox is the notification part. So maybe like every app on my phone ( allowing notifications on messages from app ) or my DHL package ( alert on shipment notifications which I subscribe ) or my bank transfers ( alert me on transfer from X ) , better option is to able to permit notifications instead of permitting publishing.
Also if we have some opt-in notification system, it can also be valuable to dapps in other ways.

@bluesign, good point that one way to reduce abuse is to ensure that publish doesn't notify the Recipient by default. But, doesn't that require that publish should not emit an event by default, unless things that consume event logs (wallets, block explorers?) are tailored to the account's individual tastes of who they want to hear from and when? That seems tricky to pull off in a way that's easier than permit - either way, the account has to have an allowlist at some level, so why not at this level? Seems like you would want to nip spam/abuse in the bud as early as possible rather than filter at a later stage.

@katelynsills It is a bit trade-off, but in practical sense, nothing will change.
If you disable notifications, you will not know there is something for you at my account, which is practically same as I am not sharing to you.
If you allow my notifications, your wallet etc can show you I shared with you something.
If you didn't allow my notifications, but somehow from some side-channel I reached you: there is no need for 3rd party to know I published you something anyway. Also this allows a semi-privacy mode. ( even though nothing private on blockchain )

@dsainati1, re: whether we should allow Resources to  be published. I think we shouldn’t, and I only just realized why.
As we know, msg.sender is bad because it makes safe, permissionless delegation impossible. There’s a list of accounts that can do X, and if I want to allow someone else to act on my behalf, they either can’t do X (not on the list), or I have to add them to the list (but maybe I don’t have admin authority over the list, and also the person I give access to can’t further delegate without themselves having admin authority to the list, and so on), or I have to give them access to my account as me. (Sidenote: maybe we should add this explanation to the documentation?)
Compare this to capability-based security: I can delegate easily by creating a capability restricted only to X and pass it to someone else.  And that other person can delegate even further in the same way.[1]
publish/claim is very much an ACL/msg.sender pattern: only a particular account can claim and delegation is impossible. For bootstrapping, this is a necessary evil - we have to start somewhere.
But if this becomes the standard way of sending things between accounts, I think this is a problem because it teaches ACLs and not capabilities. So how can we guide users such that publish/claim is only used for the initial contact between two accounts, after which they should communicate by sending things to each other’s capabilities? Not allowing Resources seems essential for that.

[1] For anyone who might be skeptical of importance of safe, permissionless delegation, imagine grocery delivery as an analogy to users receiving things from dapps. In real life, either we go to the grocery store and pick things up ourselves, or we get groceries delivered (delegation). But, unfortunately we either have to give the delivery person a key to our house (creepy!  Wouldn’t it be nice if the food we ordered appeared in exactly the right spot in our pantry and fridge? With attenuated delegation, we can do that! We can give someone access that only allows them to place items in specific spots in our pantry/fridge, and doesn’t give any access to anything else in our house. And if the grocery delivery person calls out sick, the company can get another delivery person easily, without having to add the new person to any allowlist or give the company control over who gets in my house. This enables cooperation where it was impossible before - I might trust a random person to deliver my groceries even if I would not trust them in my house.
You can imagine this same pattern of delegation expanding beyond delivery and across domains: delegating to a meal planner who selects the grocer and does the purchasing according to diet restrictions and a budget and gives the pantry access capability to the delivery company without you having to. Because there's no central authority deciding the permissions, the potential for innovation is endless.
Long story short - safe, permissionless delegation is very valuable, especially for a platform like Flow where you want to see a ton of economic activity unleashed.

publish/claim is very much an ACL/msg.sender pattern: only a particular account can claim and delegation is impossible.

But this is the whole point of publish/claim, so far: "one-on-one easy transfer with verified identity"

Wouldn’t it be nice if the food we ordered appeared in exactly the right spot in our pantry and fridge?

It is 'trade offs' all the way down, I mean we can extend on that: Wouldn't be nice if delivery person didn't know what they are delivering, or where they are delivering, or when they are delivering ?

To me this is turning out to be just a little bit more convenience over a well established pattern of capability receivers. If I have to permit things first I could as well set up a CapabilityReceiver. So then I am not sure it is worth the effort personally.

re: whether we should allow Resources to be published. I think we shouldn’t, and I only just realized why.

@katelynsills this is a pretty compelling explanation; I'm convinced it makes sense to limit this API to only sending and receiving capabilities.

To me this is turning out to be just a little bit more convenience over a well established pattern of capability receivers. If I have to permit things first I could as well set up a CapabilityReceiver. So then I am not sure it is worth the effort personally.

Hmm; can you elaborate on what the CapabilityReceiver pattern looks like?

But this is the whole point of publish/claim, so far: "one-on-one easy transfer with verified identity"

I've been assuming we were trying to solve the bootstrapping problem that Dete outlined. The user problem is: you want to give a capability to someone else, and you don't want to give anyone other than the Recipient access to the capability. You have no prior connection to the Recipient. The current solutions have major flaws:

A co-signed transaction requires both signers to be online around the same time.
A dropbox-like approach would let someone other than the Recipient get access.

Here's how Dete described the scenario:

I have a project that requires some amount of human oversight, maybe something as simple as a "pause" button that lets me block activity in the smart contract temporarily in response to a bug or market panic. As such, I have an administrator capability in my account that gives me access to call the "pause" function if necessary. In time, Bjarte joins my team, and I decide that it'd be useful if his account could also call the "pause" function in case I'm sleeping when the emergency happens. I'd like to send him a Capability for the same Admin object that I have. How do we get the Capability into his account securely?

The reason why Receivers don't work here is that they themselves fall prey to the bootstrapping problem. How does Bjarte give the receiver (a capability) specifically to Dete, and not anyone else? It's the same problem.
This FLIP really does a great job at solving this hard problem, in a way that doesn't get developers used to depending on msg.sender.

@katelynsills I think I explained this above like this:  ( this is what @bjartek refers as Capability Receiver pattern )
https://developers.flow.com/cadence/design-patterns#capability-receiver
this is already possible with:
0x2: set up account, put some resourceReceiver resource with function saveCapability(Capability)
0x2: set whitelist address: [0x1]
0x1: call saveCapability(Capability) with your capability (cap) ( 0x2: check if cap.address is in whitelist )

@katelynsills I think I explained this above like this: ( this is what @bjartek refers as Capability Receiver pattern )

Ah, good point @bluesign, thanks for the reminder!

Problem with permit is, it is no different that capability receiver. You need account set up (permitted) before publishing.

But there is an important difference, right? We don't want smart contract developers to be writing code or using code at the smart contract level that is gated on identity. That doesn't allow delegation, and it will lead developers to not understand what capabilities can do that ACLs can't.
If it's understood that permit is a platform functionality only for the initial bootstrapping, then we dodge that bullet. With permit no smart contract developer is using msg.sender patterns in their code.

But there is an important difference, right? We don't want smart contract developers to be writing code or using code at the smart contract level that is gated on identity.

Yeah but if we limit this too much and not provide a benefit, people will continue using capability receiver and implement their ACL on top of that.
We need to beat capability receiver pattern, to get usage and acceptance from developers. If we give something super restricted like this, I am afraid they will not use basically.

If I have to permit things first I could as well set up a CapabilityReceiver.

We want people to drive slow, and then offering them slower car with worse interior.

Some analogy, we want people to drive slow, and then offering them slower car with worse interior.

@bluesign, that's a really good reminder that just saying "no" to developers isn't a good strategy. I'd be interested in your thoughts on how to engage other developers in seeing the really cool things that capabilities & safe, permissionless delegation can do. This FLIP seems like the wrong place for it, but that kind of discussion seems very valuable. I think allowing capabilities to have behaviors themselves and expanding beyond the facet pattern would help, but that's also outside the scope of this FLIP.
To continue your analogy, I think we should enforce a speed limit when we know it's a dead-end and there's a brick wall ahead (otherwise all our drivers are going to die in a fiery crash), but we also should tell the drivers that there's a high speed train right nearby that will let them go faster than any car would. And if the high speed train isn't built yet, we need to work on getting there :)

How do we currently do bootstrapping? We use Capability Receivers.
A short rundown of that (with S as the Sender a.k.a.: the flow account that wants to send/give a capability, and R the Receiver the flow account that is to receive this capability):

off-chain: S notifies R that it wants to send a capability to it (with a specific type!)
on-chain: R creates a capability receiver for that capability and exposes it publicly.  This could happen by:

R telling S off chain
R triggering a designated on chain event
S pooling R for the existence of the receiver

on-chain: S sends the capability to R
on-chain: cleanup:

R removes the receiver

What are the problems:

This is a lot of steps
Implementing a receiver correctly is not a given (and could be easily attacked if not correct). R might not know anything about receivers and how to correctly implemented and will just grab a recipe from somewhere, or worse, trust S to provide code on how to implement the receiver.
S needs feedback on R being ready before it can proceed

What I think the solution is:
The original proposal had just AuthAccount::Publish(value, name, account) and AuthAccount::Claim(name, address): value (and of course you need unpublish as well), let me talk about that for a bit (and lets assume the value is a capability only).
These functions change the bootstrapping pattern to:

on-chain: S publishes a capability for R (lets say by default no events get emitted)
off-chain: S notifies R that it published a capability
on-chain: when R has time. R claims capability

Much simpler!

by step 2. S is done
before step 3. R doesn't have to do anything.
S doesn't have to clean up, no-one else can claim the capability besides R (even if claiming wouldn't automatically un-publish it). S can clean up to save space (or if S has changed its mind about sharing at which point it should also un-link the capability just to be safe)
R does not have to write any custom code, it only has to store the capability somewhere, so It can use it later.

At this point there were questions about spamming and weather or not to send a common event when something is published. Can R be spammed, by constantly publishing for R?
I don't think so.
It's not like there is a notification popping up (on-chain) for R every-time someone publishes something for R.
If S wants to let R know it published something S has to do that off-chain (and let the off-chain channels like gmail and slack deal with any spam :smiley:  ).
This is also the reason why there should not be a common chain event triggered when publishing. If there would be, people could rely on listening to them, at which point they could be spammed.
If S really wanted to it could still emit a (custom) event when publishing (maybe by wrapping the publish action in a smart contract function that also emits an event).
So in short I think something like this would be sufficient (I probably got the generic notation wrong) (these are all on AuthAccount):
fun publish<T: Any>(capability: Capability<T>, name: String, recipient: Address) // does not emit an event
fun unpublish(name: String, recipient: Address)
fun claimFrom<T: Any>(name: String, provider: Address): Capability<T>? // does not un-publish

(I don't see the argument for needing to permit before something can be published
(ab)use for other things than bootstrapping
I don't think this is a  very efficient way of sending things, especially if we limit this to only capabilities.  The reason is that S must notify R off-chain that something is available to be picked up. If S and R intend to exchange a lot more stuff (than just one capability) maybe instead of going through bootstrapping each time, they should instead bootstrap a (pull) channel where S gives the capability to pull from the channel to R and for further sharing S just pushes more stuff to the channel.
How that channel looks like is up to S and R, but I would imagine that S would want to emit an on-chain event that R knows about when adding to the channel.
Some other (random) thoughts:

instead of publish/claim, wrap/unwrap could be used, where wrapping a capability into a WrappedCapability<T> makes it so that only the specified account can then unwrap it back into Capability<T>. This allows for the same pattern (of bootstrapping) but S had to provide its own way to serve WrappedCapability<T>s instead of publish providing this. On the other hand it might be more flexible, and allow for more patterns.
instead of publish/claim, we could use identity as in S can provide something to someone who can provide the identity of R (which is only R) but the problem with this is that the identity object would need to be sent into a function, and once it goes into a function S could capture it and pretend it is R.
If S knows for certain that R and only R can pick up the published capability, S can wrap the capability with a wrapper that basically says that "if anyone calls this R is to blame"

If we decide for sure that no events are emitted, and the potential spam doesn't clog up block explorer displays, it makes sense to me to leave out permit as a step 👍

Hmm; can you elaborate on what the CapabilityReceiver pattern looks like?

https://developers.flow.com/cadence/design-patterns#capability-receiver

This is also the reason why there should not be a common chain event triggered when publishing. If there would be, people could rely on listening to them, at which point they could be spammed.
If S really wanted to it could still emit a (custom) event when publishing (maybe by wrapping the publish action in a smart contract function that also emits an event).

I do not agree on this. I think a shared event should be emitted. Why is this "spamming" a problem here? Or is this something you claim? The benefits of emiting a shared event is numerous!
In .find we could listen to 1 event to know if a user has anything published to them, and then prompt them to accept it, or flow port could do the same.
Shared events also signal that an mutation has happend on chain and that is a documented best practise. We should use more shared events, not less. Visbility is important.

If we decide for sure that no events are emitted, and the potential spam doesn't clog up block explorer displays, it makes sense to me to leave out permit as a step 👍

I feel significantly less concerned about this capability spam than you seem to be.
This is not equivilent to token spam in ethereum because it doesn't create the same attack surface where a user further gives approval to their whole account to a malicious contract. Critically, the attack that's most concerning is actually having a token in your possession that looks valuable but is malicious.
If massive spam is a problem then it would mean that spammers would just be making themselves less visible, since there would be lots of noise in block explorers.
Even on networks with low fees, I have public accounts that have received some token spam but it's not THAT high. In this case the EV of the attack is so low that id be willing to ignore it so long as there's significant dev advantage to having a standard event.

Even if we decide to not emit events, I still think allowing an open connection between any two accounts by means of this API does still pose an issue that @katelynsills mentioned earlier:

For instance, imagine a motivated and coordinated harassment attack, where the Recipient keeps getting notifications where the string name is used to send threatening and abusive messages. Thus, there needs to be an easy way to revoke this connection between accounts.

If we don't want to require an initial permit step here in order to keep the happy path simple, there does still need to be some kind of block functionality or similar so that users do not have to be connected to abusive accounts if they do not wish to be.

Does this actually need to be a protocol level concern?
Seems this type of blocking would be an application feature.

The accounts are not connected.
The Sender needs to notify the Recipient off-chain.
The only possible on chain connection they have, that would allow for abusive messaging is the common event emitted during publishing.
I imagine that event would contain:

a source address (Senders address)
a destination address (Receivers address)
the name of the provided value/capability
possibly the type provided

If this event would exists I imagine people would want to listen to anything that was published for them, which opens them to receive spam (with a custom message in the name field).
The workaround would be just listening to list of specific sources, but in this case I argue that its better to not have a common event and just let every sender define which event they are going to emit. If need be people can still opt to create a standard to follow where they would emit a certain event defined in a common contract somewhere.
@bjartek @pgebheim  I still feel that there should not be a common (cadence-level) event emitted when publishing. But this is the only argument I have.
I can perhaps suggest that we add the feature without the common event and open a separate discussion/PR for the common event.

If this event would exists I imagine people would want to listen to anything that was published for them, which opens them to receive spam (with a custom message in the name field).

In my eyes this is a non-issue. There are numerous other ways a user can be spammed today. How many active users do not have a FLOAT account? A float user can be airdropped any NFT per the NFT standard.
In Lost-And-Found you can add any resource or an NFT and send to a user and add a message.
I have several more use cases where on chain "spam" is inevitable.
We need a common event or a way to onChain know if a user has something to claim for them.

For what it's worth, here's a real life example of the kind of abuse and harassment that I'm concerned about. Specifically, it's the name field that would be used to transmit a hateful message. An attack like this would prevent the recipient from being able to be use Flow at all.
One option that I haven't seen discussed yet is to keep the default open (anyone can publish to anyone, and every publish emits an event) but allow users to turn on an "Advanced Protection" mode in which they only accept published capabilities from accounts that they explicitly permit access. Seems like that could be the best of both worlds in terms of usability and security.

@katelynsills that is a really good example, and my point is that doing that is very easy already. And doing so in tools that is way easier available then this solution that is something that most likely only very technically savvy users/developers will user either way.

my point is that doing that is very easy already

I am not convinced that this is a particularly compelling argument; just because a bad practice is commonplace already does not excuse us as designers if we contribute to the problem by adding another vector for harassment.

We had a public meeting about this FLIP today (Sept 26) and we settled on a few specific steps forward here:

Spam and harassment via events or messages is the responsibility of the user actor (e.g. the wallet) to manage, rather than the protocol, so we will remove the allowlist, permit and unpermit sections of this proposal in favor of these things being handled off-chain. We will likely suggest to wallet or other user actor developers that they do not display publishing events as-is to users, and allow users to restrict who they see events from.

publish, claim, unpublish should all emit an event to signify that a capability has been published or removed, containing the name, type, and receiver (in the case of publish) and the name and removing account (in the case of claim and unpublish). This will give accounts the information they need to claim resources when they are published for them.

For now, the API will continue to be restricted to capabilities. In the future we may decide to expand this to resources, but this would not be a breaking change (whereas going from resources now to capabilities in the future would be).

claim should remove the capability being claimed from the publisher's dictionary. While capabilities can be duplicated, so it would not be semantically wrong to leave a copy present, leaving the capability in place would require manual cleanup on the part of the publisher that is not desirable. It would also encourage a pattern where receivers would repeatedly claim capabilities stored on the publisher's account whenever they need them, in order to avoid paying for the storage for that capability themselves.


DbContext optionsBuilder.UseSqlServer missing reference

Hello, I am sorry for the basic issue but there is no where else to get help on Blazor,
I am trying to make a DbContext class and when I try to use optionsBuilder.UseSqlServer("connection string") I get an error stated below
I am trying to add the reference Microsoft.EntityFrameworkCore.SqlServer but there is no option for it in the dependencies reference manager, and simply typing using Microsoft.EntityFrameworkCore.SqlServer; does not work either.
I tried to use nuget package manager to install the sql server package, and i get a warning stating I downgraded and that it was restored, yet I do not see it installed as a nuget package so I assume that the project template comes with it pre installed yet I am still getting this error. Please help.
Error	CS1061	'DbContextOptionsBuilder' does not contain a definition for 'UseSqlServer' and no extension method 'UseSqlServer' accepting a first argument of type 'DbContextOptionsBuilder' could be found (are you missing a using directive or an assembly reference?)	BlazorCRUD.Shared	C:\Users\User\Desktop\BlazorCRUD\BlazorCRUD.Shared\DataAccess\EmployeeContext.cs	15	Active

`using BlazorCRUD.Shared.Models;
using Microsoft.EntityFrameworkCore;
namespace BlazorCrud.Server.DataAccess
{
public class EmployeeContext : DbContext
{
public virtual DbSet tblEmployee { get; set; }
    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        if (!optionsBuilder.IsConfigured)
        {
            optionsBuilder.UseSqlServer(@"Put Your Connection string here");
        }
    }
}

}
`

Is this the server side of an ASP.NET Core hosted blazor app or are you trying to run EF in the browser? While i don't know if EF can run in the Browser, the SqlServer client definitely does not as it relies on Socket connections. If this question is about EF on the server side, it's not blazor specific.

Ah i suppose youre right. It is on the server side, sorry is there a way to remove this?


nice-to-haves and possible features

Nice-to-haves
Things we will maybe implement, but aren't necessary for the workflow of the application.

[x] tooltips
[ ] select-students:detail: change suggestion modal to select project and skill and confirm the decision
[ ] suggestion: suggest project (backend is able to do this)
[ ] projects: show who added a student to a project
[ ] project: skills / student show extra detail on hover
[ ] github login

Possible features
Things we won't implement and aren't necessary for the workflow of the application.

[ ] select-students : searchbar : per letter search
[ ] option to auto delete edition after x years

Concerning my comments in pull #496. Instead of changing the backend to show who assigned a student to a project we could add this to the text of the reason. It might not be the most proper solution but it is a quick solution and users would immediately see who gave the reason.

I'd rather change it in the backend then, else any user can say someone else made the participation.
It isn't much work tho, but won't it be a problem for /ddd? because in the code where you generate the participations we would need to add a user as well?
I suggest I make the changes in backend and frontend, and you or @Vital7788 help me with changing ddd, then it will be done in like 2-3h I think.


VS Code_Bundle_NuGet_SQL_Service Bus_Not able to fetch the queue name automatically.

Describe the Bug with repro steps

Create a project in VS Code and add stateful workflow.
Open the Designer, add the HTTP trigger.
Add Service Bus and create the connection.
Try to fetch the queue name : The queue name is not fetching automatically but after using the custom value it is working fine.

Workflow JSON
No response
Screenshots or Videos

Browser
VS Code
Additional context
Expected: Queue name is to be fetch automatically.
Actual: Queue name is not fetching automatically.
System Info:
VS Code extension - vsix icon vscode-azurelogicapps-2.0.26.vsix
NuGet package: https://artprodeussu2.artifacts.visualstudio.com/A41bf5486-7392-4b7a-a7e3-a735c767e3b3/b32aa71e-8ed2-41b2-9d77-5bc261222004/_apis/artifact/cGlwZWxpbmVhcnRpZmFjdDovL21zYXp1cmUvcHJvamVjdElkL2IzMmFhNzFlLThlZDItNDFiMi05ZDc3LTViYzI2MTIyMjAwNC9idWlsZElkLzcxMzU5ODUxL2FydGlmYWN0TmFtZS9kcm9wX2J1aWxkX0J1aWxkQXJ0aWZhY3RzX1dpbmRvd3M1/content?format=file&subPath=%2FMicrosoft.Azure.Workflows.WebJobs.Extension.1.17.1.nupkg
Extension Bundle (CDN URL): https://cdnforlogicappsv2.blob.core.windows.net/logicapps-vendortesting
Extension Bundle (Direct Download): https://cdnforlogicappsv2.blob.core.windows.net/logicapps-vendortesting/ExtensionBundles/Microsoft.Azure.Functions.ExtensionBundle.Workflows/1.17.1/Microsoft.Azure.Functions.ExtensionBundle.Workflows.1.17.1_any-any.zip

Issue is seeing for the first time only when service is adding and trying to fetch the queue name for the first time.


Illegal argument causes set_ee_cartesian_trajectory to crash

https://github.com/Interbotix/interbotix_ros_toolboxes/blob/1ed10f99f9ce7d5d77f65b5756d8f3f7a06bdc1e/interbotix_common_toolbox/interbotix_common_modules/src/interbotix_common_modules/angle_manipulation.py#L52
np.identity() does not have any keyword like (this keyword has been introduced from numpy v1.20)
this crashes the set_ee_cartesian_trajectory method
https://github.com/Interbotix/interbotix_ros_toolboxes/blob/1ed10f99f9ce7d5d77f65b5756d8f3f7a06bdc1e/interbotix_xs_toolbox/interbotix_xs_modules/src/interbotix_xs_modules/arm.py#L247

If your numpy version is lower than what is required, you should be able to upgrade it by running the following command:
$ pip install numpy --upgrade # or pip3 if on noetic

Let us know if this does not resolve your issue.


Update your ABOUTME

Follow the example for johndoe.md under doc/team

Not all member's have been completed yet


updating date parsing

Codecov Report

Merging #70 (c6a1b44) into master (96e3e7c) will decrease coverage by 0.24%.
The diff coverage is 61.11%.

:exclamation: Current head c6a1b44 differs from pull request most recent head 844dee8. Consider uploading reports for the commit 844dee8 to get more accurate results

@@            Coverage Diff             @@
##           master      #70      +/-   ##
==========================================
- Coverage   83.07%   82.82%   -0.25%
==========================================
  Files          17       17
  Lines        1967     1980      +13
==========================================
+ Hits         1634     1640       +6
- Misses        194      200       +6
- Partials      139      140       +1


Featured campaigns legend #1504

This PR adds a legend to the campaigns list explaining that the campaigns with a star are featured. It also adds a tooltip to the stars.
Resolving issue #1504

Thanks @DanielSchiavini This looks great.
:shipit: now.


loading screen can get you stuck

idk you can go into a menu and get stuck on the loading so just uh fix it i guess
im tired

it means the engine wasn't found or there was an error in the console

added a text for that in 8138c002d18017a6f90be7edd57243218bcfecb8

There should be no issues now because of the new database 😄
Also, new parameters will require just assigning them in the editor since it's pure JSON now. Updating the database will also be easy


[Bug?]: useLocation not updating during nested route changes

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Current behavior 😯
When you use nested routing via the Outlet component, the A keeps the activeClass and aria set to current for the every path of the child Outlet.
For example, with the current route structure:

@me.tsx (global nav)

(@me).tsx
profiles.tsx

The attributes will remain active no matter if the URL is either /@me or @me/profiles. This seems to be due to the router not recognizing the change in the child pathname via the const { pathname } = useLocation() hook.
Expected behavior 🤔
The useLocation hook should be able to identify the route structure and URL change with nested routes using the Outlet component.
Steps to reproduce 🕹
Steps:

Create a new SS project using SSR
Create 2 levels of routing using the Outlet component with a global nav in the parent
Set active styles for the A component
Navigate to different child pages
🛑 LINKS DO NOT CHANGE - validate in the dev console and aria attrs and log with useLocation hook

Context 🔦
When you log the result of const { pathname } = useLocation() it appears the parent is not updating the pathname even though a route  and pathname changes. The A component logic looks fine, so it seems to be a router issue?
Your environment 🌎
"dependencies": {
    "@solidjs/meta": "^0.28.2",
    "@solidjs/router": "^0.8.2",
    "rollbar": "^2.26.2",
    "sanitize.css": "^13.0.0",
    "solid-js": "^1.7.7",
    "solid-start": "^0.2.26",
    "undici": "^5.15.1",
    "yup": "^1.2.0"
  }

that's the intended behavior, if you want activeClass to only work if the route is exactly the same you can use the "end" attribute. You can check the docs: https://docs.solidjs.com/guides/how-to-guides/routing-in-solid/solid-router#creating-links-to-other-routes


Change dbsubnetgroup.DBSubnetGroup from Listing<String|Mapping> to Listing<String|Mapping>|Mapping

Currently, it doesn't support this kind of use:
Resources {
	["SubnetGroup"] = new dbsubnetgroup.DBSubnetGroup {
		// ...
		SubnetIds = cfn.Ref("SubnetsIds")
		// ...
	}
}

It forces you to receive multiple subnet parameters to be passed directly in a listing, like this:
Resources {
	["SubnetGroup"] = new dbsubnetgroup.DBSubnetGroup {
		// ...
		SubnetIds = new Listing {
			cfn.Ref("SubnetId1")
			cfn.Ref("SubnetId2")
			cfn.Ref("SubnetId3")
		}
		// ...
	}
}

The idea is to fix it and allow using refs directly

Seems like we need to do this for all array types.


docs(aio): URL to DatePipe in Glossary

What kind of change does this PR introduce? (check one with "x")
[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[X] Docs fix
What is the current behavior? (You can also link to an open issue here)
"...so you can reset ... at the same."
What is the new behavior?
"...so you can reset ... at the same time"
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[X] No

Why was this PR closed?

Did you read the warning when you tried to create it?

No I didn't read it. But help me out a new contributor

You can start by reading it. Then we can move to the next step :)

Shall I raise another PR

Yes, following the steps written in there :)

Yes, got it. wrong repository correct me if I m wrong again .. Created a new PR https://github.com/angular/angular/pull/16437


Encrypt/Encrypt instead of Encrypt/Decrypt in test.c

Hello
There is an error in test.c. Both functions test_encrypt_ctr and test_decrypt_ctr are calling test_xcrypt_ctr which executes the exact same code in both cases so it is encrypting two times instead of encrypting and decrypting. This causes confusion because it is not clear how to use the AES_CTR_xcrypt_buffer API.
If it is the same function for Encrypt/Decrypt as mentioned in the .h file, how come there is no input parameter indicating what is to be done? And the test is not exercising the decryption.

Hi. That’s how CTR works! Please see the Wikipedia page - this diagram is the epiphany :)
https://upload.wikimedia.org/wikipedia/commons/thumb/3/3c/CTR_decryption_2.svg/640px-CTR_decryption_2.svg.png
On 11 Jun 2019, at 20:14, Manuel Malagon <notifications<EMAIL_ADDRESS>wrote:
Hello
There is an error in test.c. Both functions test_encrypt_ctr and test_decrypt_ctr are calling test_xcrypt_ctr which executes the exact same code in both cases so it is encrypting two times instead of encrypting and decrypting. This causes confusion because it is not clear how to use the AES_CTR_xcrypt_buffer API.
If it is the same function for Encrypt/Decrypt as mentioned in the .h file, how come there is no input parameter indicating what is to be done? And the test is not exercising the decryption.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/kokke/tiny-AES-c/issues/141?email_source=notifications&email_token=ABBU2HCNLM3PS5AOQACYVO3PZ72PNA5CNFSM4HXCRMB2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GY4SY4Q, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABBU2HGUDDIW4WRS6FM53NDPZ72PNANCNFSM4HXCRMBQ.

@ifknot thanks for the tip. That explains how it works.
But that doesn't clarify why in both cases, encryption and decryption, in test.c this is being executed:
AES_CTR_xcrypt_buffer(&ctx, in, 64);
We can see that only in is used because the exact same function is being called for both test_encrypt_ctr and test_decrypt_ctr and since it is not global or static and there is nothing in the code indicating that for decryption out should be used, then both test_encrypt_ctr and test_decrypt_ctr are encrypting twice using in* and comparing it with out and never using out and comparing with in.

Hi @m4l490n and thanks for your interest in this project :)
See this old issue, asking somewhat the same question as you:
https://github.com/kokke/tiny-AES-c/issues/78
The short explanation: The reason for this odd test, is to reflect the test procedure described in the NIST-document used for verification, SP 800-38A. This is actually how they say the test should be done :D

Closing the issue as a duplicate of #78 - feel free to continue posting if you have questions or comments Manuel :)


CONNECTOR-915 Support Info Requests + Whitelisting

It's a draft PR, before merge its required to publish a new proto version (aerospike-proxy-proto:1.0.1) and use it as a dependency in the stub build.gradle.kts (I built locally and used 1.0.1-SNAPSHOT locally).

@ashishshinde Pushed SNAPSHOT versions to build.gradle.kts and published to JFrog


🐛 Bug Report: Error when uploading large files (over 5 MB) with Appwrite SDK for Flutter (SDK Version: 9.0.1, Server Version: 1.3.3)

👟 Reproduction steps

Initialize the Appwrite SDK in a Flutter application (version 9.0.1).
Use the SDK to send a file upload request to the Appwrite server (version 1.3.3) with a file larger than 5 MB.
Observe that the upload process gets stuck after sending the first part of the file (approximately 5 MB).

👍 Expected behavior
I expected the Appwrite SDK to successfully upload the entire file larger than 5 MB without any issues.
👎 Actual Behavior
The Appwrite SDK only uploads the first part of the file (approximately 5 MB) and then the upload process gets stuck.
flutter: UploadProgress($id: 64b648843534b29877ad, progress: 80.5257811319271, sizeUploaded: 5242879, chunksTotal: 2, chunksUploaded: 1) flutter: {message: Server Error, code: 500, type: general_unknown, version: 1}
🎲 Appwrite version
Different version (specify in environment)
💻 Operating system
MacOS
🧱 Your Environment

Appwrite Server Version: 1.3.3
Appwrite SDK for Flutter Version: 9.0.1
Flutter Version: 3.12.0-15.0.pre.29 (Channel master)
Operating System: macOS 13.4.1 (Darwin-x64)
Locale: fr-FR

Additional Information
I apologize in advance for any confusion in my explanation due to my limited English proficiency.
I have thoroughly searched through the Appwrite SDK documentation, existing issues on the official repository, and various online resources for several weeks, but haven't found any solution to resolve this issue with larger files.
I can confirm that the Appwrite server (version 1.3.3) is properly configured to handle large files, as I can successfully upload 20 MB files using the server's web interface on my portable device.
I have also tested this functionality on both a real device and a simulator, and the issue persists, indicating that it is not platform-specific.
I appreciate any assistance and guidance in resolving this issue, as it is essential for the proper functioning of my application.
Thank you very much for your help!
👀 Have you spent some time to check if this issue has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Hello everyone,
I am happy to inform you that the bug was not coming from the Flutter SDK but from my server. I updated and reinstalled everything, and now it's working correctly. So, I'm closing the issue.
Thank you all for your support and help!


Ressources

Here comes ressources, that are, where or will be usefull?
The logic flow:
madn.md
The empty gamePiece:

this is how the "packers" are send:
menschADN_packets.txt


Essence roadmap

Our plans for the next period are:

[x] support for React v0.14.x - #36

[x] release on NPM (minor version bump) - #34

[x] do some cleanup, remove unwanted files from NPM package

[x] close all resolved issues - #34

[x] solve and close all unresolved issues

[x] release on NPM (patch version bump)

[x] fix styling inconsistencies with Google Material Design specs #18 #9 #40

[x] move build process to Webpack && Babel (we're still using old stuff on this one) #38

[x] break Essence in smaller modules and move to ES2015

[x] react-essence-core (block, divider, highlighter, ripple, text)
[x] react-essence-app-bar
[x] react-essence-bottom-sheets
[x] react-essence-button
[x] react-essence-card
[x] react-essence-chip
[ ] react-essence-date-picker
[x] react-essence-dialog
[x] react-essence-icons
[x] react-essence-image
[x] react-essence-text-fields
[x] react-essence-list
[x] react-essence-menu
[x] react-essence-navigation
[x] react-essence-paper
[x] react-essence-progress
[x] react-essence-slider
[x] react-essence-snack-bar
[x] react-essence-switch
[x] react-essence-tab
[x] react-essence-toast
[ ] react-essence-toolbar

[x] new Essence components based on Google Material Design

[x] react-essence-data-tables
[x] react-essence-steppers
[x] react-essence-badge

[x] remove React from Essence source code

Hi @CoveTechnologyAus
Thanks for the positive feedback, I think next week we would finish the essence-toolbar component and starting build the date-picker / hour-picker.

NOTE: If you are wondering why is taking this so long is that we are in the process to move all our components LESS styles from display: block to display: flex

That's awesome news, we will wait for essence-toolbar, we will be able to start with that and wait for the date/hour picker... keep up the great work, from the "mini" projects I have created to test this framework, I think it is definitely the goods :+1:

Hi @JasonWeise
I'd manage to finish building the essence-toolbar so you can test it today or this weekend :)
You can visit the component at NPM https://www.npmjs.com/package/essence-toolbar
So you can install and use it as follows:
npm install essence-toolbar

import ToolBar from 'essence-toolbar';

class ToolBarTest extends React.Component {
    render() {
        return(
            <div>
                <ToolBar>This is a simple toolbar</ToolBar>
                <ToolBar floating={true}>This is a floating toolbar</ToolBar>
                <ToolBar bottom={true}>This is a bottom fixed toolbar</ToolBar>
                <ToolBar noShadow={true}>This is a toolbar without shadow</ToolBar>
            </div>
        );
    }
};

With options:

floating: boolean - default false
bottom: boolean - default false
noShadow: boolean - default false

or you can combine bottom: true and noShadow: true

NOTE: next week we will finish the essence-date-picker & essence-hour-picker