Registering Rancher managed clusters in Argo CD doesn't work out of the box unless the Authorized Cluster Endpoint is used. Many users will prefer an integration of Argo CD via the central Rancher authentication proxy (which shares the network endpoint of the Rancher API/GUI). So let's find out why registering clusters via Rancher auth proxy fails and how to make it work.
Hint: If you are just looking for the solution scroll to the bottom of this page.
| function test_get() | |
| local r = http_create() | |
| http_set_resolver_protocol(r, "any") | |
| http_set_protocol(r, "https") | |
| http_set_host(r, "postman-echo.com") | |
| http_set_port(r, 443) | |
| http_set_verifymode(r, "verify_peer") | |
| http_set_target(r, "/get?foo=bar&onset=nice") | |
| http_set_verb(r, "get") |
| RAR registration data | |
| WinRAR | |
| Unlimited Company License | |
| UID=4b914fb772c8376bf571 | |
| 6412212250f5711ad072cf351cfa39e2851192daf8a362681bbb1d | |
| cd48da1d14d995f0bbf960fce6cb5ffde62890079861be57638717 | |
| 7131ced835ed65cc743d9777f2ea71a8e32c7e593cf66794343565 | |
| b41bcf56929486b8bcdac33d50ecf773996052598f1f556defffbd | |
| 982fbe71e93df6b6346c37a3890f3c7edc65d7f5455470d13d1190 | |
| 6e6fb824bcf25f155547b5fc41901ad58c0992f570be1cf5608ba9 |
| # Fortement inspiré de cet article: http://rabexc.org/posts/docker-networking | |
| # Tester les performances réseaux de ses conteneurs docker | |
| # avec docker-proxy | |
| docker run -it --rm --name=iperf3-server -p 10000:5201 networkstatic/iperf3 -s | |
| docker inspect --format "{{ .NetworkSettings.IPAddress }}" iperf3-server | |
| iperf3 -c 172.17.0.2 ⇒ 37gbs | |
| iperf3 -c localhost -p 10000 | |
| # désactiver docker-proxy | |
| vi /etc/docker/daemon.json |
According to Apple, the only way to remove an unknown firmware password from a MacBook (2011 and later) is to take it to the Apple Store with the original proof-of-purchase. However, I've found that there is another way, which I've been successful with for the unibody MacBook Pro--it's essentially just modifying a couple bytes in the EFI ROM, which should be simple. What's not simple, however, is figuring out how to read and write to the EFI chip. In this post, I'll talk about the process that I figured out and what worked for me.
Apple's method of resetting the firmware password is not reproducible, as Apple generates an SCBO file that unlocks the EFI using their private key. You can read more about this process here. The problem with this system is that, if you are in the unfortunate situation of neither having the firmware unlock pass
Ce document décrit les techniques que j'ai utilisées sur le challenge #BlackBadge conçu par @virtualabs à l'occasion de la conférence LeHack 2019.
Cette année, le badge LeHack a attiré mon attention sur Twitter car il embarquait un peu d'électronique, à savoir une piste formant une bobine et une LED soudée à son extrémité :
| [Trigger] | |
| Operation = Remove | |
| Type = Package | |
| Target = * | |
| [Action] | |
| Description = Clearing cache... | |
| When = PostTransaction | |
| Exec = /home/<user>/.local/bin/tools/removehook |
The big "make everything stateless" hype is just that: hype. Your server-side application code, should usually be stateless, because this makes your application more resilient to errors, easier to scale, and easier to reason about. But there are exceptions to even that, especially for stuff like video game servers.
Your services are almost always going to be stateful, and should be. If you have a database, files, or literally anything that affects the responses the server sends, then the service is not stateless.
So building "stateless" services is a lie. You shouldn't strive to make your services stateless, you should make sure you're putting your state in the correct place.
| default['sshd']['sshd_config']['AuthenticationMethods'] = 'publickey,keyboard-interactive:pam' | |
| default['sshd']['sshd_config']['ChallengeResponseAuthentication'] = 'yes' | |
| default['sshd']['sshd_config']['PasswordAuthentication'] = 'no' |
TLDR: JWTs should not be used for keeping your user logged in. They are not designed for this purpose, they are not secure, and there is a much better tool which is designed for it: regular cookie sessions.
If you've got a bit of time to watch a presentation on it, I highly recommend this talk: https://www.youtube.com/watch?v=pYeekwv3vC4 (Note that other topics are largely skimmed over, such as CSRF protection. You should learn about other topics from other sources. Also note that "valid" usecases for JWTs at the end of the video can also be easily handled by other, better, and more secure tools. Specifically, PASETO.)
A related topic: Don't use localStorage (or sessionStorage) for authentication credentials, including JWT tokens: https://www.rdegges.com/2018/please-stop-using-local-storage/
The reason to avoid JWTs comes down to a couple different points:
