Per their response to this issue, seems like this is a bug: While they do have some non-FOSS code in their `sdk` package, the client should still be buildable without the SDK:
> Hi @brjsp,
> Thanks for sharing your concerns here. We have been progressing use of our SDK in more use cases for our clients. However, our goal is to make sure that the SDK is used in a way that maintains GPL compatibility.
>
>
> the SDK and the client are two separate programs
> code for each program is in separate repositories
> the fact that the two programs communicate using standard protocols does not mean they are one program for purposes of GPLv3
> Being able to build the app as you are trying to do here is an issue we plan to resolve and is merely a bug.
The problem with that statement is what exactly does "in a way that maintains GPL compatibility" means, especially since they plan on moving more functionalities into the proprietary code, so the two "separate" components will be increasingly coupled together.
I'm not a lawyer, but I'm quite skeptical of the outcome. Is it really going to produce a valid GPLv3 licensed client? To me, it seems like the whole thing is just going to be a combined proprietary + GPLv3 license, which will contradict itself.
But again, I'm not a lawyer, so my understanding of this might be way off.
Yup, and there we can see the password is just splatted in with no salt. 99%+ the password is an injection attack too, but one only needs one set of the keys to the kingdom to make the point, so the article never discusses getting in via password instead and the author may well never have checked, because it couldn't make things any worse.
The screenshot in the article shows MD5() is returned as part of the error message from the web server, so it is probably also a part of the original server-side query.
This brings back memory: This was the case for a gold-buying website for the Runescape game in the 2000s. You could edit your cookies or other front-end facing information to change the price of items in your cart, so you could buy gold or items for much cheaper than the market rate.
At some point, while the vulnerability remained, they started cancelling orders abusing this and manually checking the orders.
I think you could still find some old youtube videos or threads on obscure forums with enough digging about that topic, that's how I learned of it initially.
+1 to echarts: While it can be more complex to start than the others, it remains fairly simple for the default graphs while providing enough flexibility to do pretty much anything.
‘Using echarts and provided DATA, demonstrate how to convert a table of rows such that the “value” is aggregated and shown on a bar chart as the sum of all “values” for each “timestamp”
DATA: {json array}’
Dumping your data into the context window tends to help specify the task and focus the AI on the data structures to use.
Same here: I've been hosting two dozen services on Dokku for a side-project in the past few years and it's been working flawlessly!
Dokku and a Hetzner server makes hosting very easy
AWS did not launch their own spinoff alone, but instead joined the Valkey project by the Linux Foundation[0], alongside many other major contributors:
> Industry participants, including Amazon Web Services (AWS), Google Cloud, Oracle, Ericsson, and Snap Inc. are supporting Valkey. They are focused on making contributions that support the long-term health and viability of the project so that everyone can benefit from it.
Seems like a good alternative to a single company's spinoff: Many major providers working on this same project should result in everyone benefiting from it.
Is this related to the react-spreadsheet[1] project? Where does the "React Spreadsheet 2" from the title come from?
It's not clear if this is an update to the project, a fork of an existing project, or something brand new.
> Hi @brjsp, > Thanks for sharing your concerns here. We have been progressing use of our SDK in more use cases for our clients. However, our goal is to make sure that the SDK is used in a way that maintains GPL compatibility. > > > the SDK and the client are two separate programs > code for each program is in separate repositories > the fact that the two programs communicate using standard protocols does not mean they are one program for purposes of GPLv3 > Being able to build the app as you are trying to do here is an issue we plan to resolve and is merely a bug.