Yeah what I wrote was just something to get the idea out, about having a list of Allowables.

I just fully read your code, and I like how you changed the Allowable api to have a deny and allow function instead of it being at the AllowList level. Honestly, I did not know mem::take was a function. I like how you got around cloning too.

Also, just so you know, you come off pretty rude. Just want to make sure you know that if you're not aware.

  • source
  • parent
  • context
  • [–] 2 points 2 days ago (2 children)

    How is it a code smell? I'm pretty sure interior mutability is a well established design pattern. I'm not really familiar with the pattern you're describing using Ref/RefMut wrapping, could you show me what you mean?

    Yeah I didn't want to pour a bunch of time into wrangling borrow checker stuff for a small code snippet.

  • source
  • parent
  • context
  • [–] 2 points 3 days ago* (4 children)

    Finally got around to writing the code, here's the link to the Rust playground with it. I was too lazy to do the unsafe stuff, but where I call clone in the deny and accept functions are where you'd rewrite and do unsafe magic to swap out elements without the clone overhead.

    I also tried to implement a take function (like in Option) for the Allowable enum. Transferring ownership like with take would keep you in safe land and get what you want done.

    Keep in mind I am not a game dev. I don't do cache optimizations. I have no idea how this code would function in a game context, but this is just my first idea for implementation of what you asked.

  • source
  • parent
  • context
  • [–] 4 points 3 days ago* (5 children)

    What are the conditions for T to be accessed? You could potentially wrap each instance of T in an enum that has two states, Allow and Deny, where if you encounter a Deny you just don't access that one. If you have a slice of this enum where each enum owns T, you can always just swap out a Deny for an Allow or vice versa depending on how you want to do it. If you go this route, you might want to make a struct that owns the vector mutably, can return an immutable borrow to the slice, and change permissions on the slice. Now that I'm thinking about it, you can also implement a gets function on the struct that would return a Result depending on whether it was an allow or a deny. I don't think you'd need unsafe with this.

    The solution mostly depends on the context surrounding how you're managing what can access T and at what time. I can see the solution I proposed not working if you need more specific permissions than allow or deny, or if the permissions are based on the caller.

    Edit: I'm going to come back in a few hours and write code about what I mean in the first paragraph.

  • source
  •  

    Preface: I wrote this tutorial for two reasons. More people should learn torrenting, and I want people to listen to my album.

    What is torrenting?

    Torrenting is a distributed file sharing system that basically lets you have really fast upload and download speeds if there's enough people. All the people sharing amongst each other is called a swarm. There's three types of users of a torrent that are commonly referred to: seeds, peers, and leeches.

    Seeds - These are the people that have the whole file and are now sharing it with other people.

    Peers - These are people that are uploading and downloading the file. They have a partial version of the file, but because torrenting shares files in pieces, they can start sharing pieces once they have them.

    Leeches - These are people that download the file and then just turn off their torrenting program and don't share. Don't be these people.

    How to start

    I'd recommend starting with qBitTorrent. It's easy to use, and right now is the gold standard in torrenting software, as far as I know. Additionally, your OS might have an actively maintained package for it, so look for that first! You'll also need a VPN. I'm using Mullvad VPN for this guide.

    Opsec

    One thing to remember about torrenting is that it is a peer to peer network. This means that your computer will be directly connecting to others. Other computers will see the IP address that you're torrenting on. Commonly, ISPs will detect torrenting and I've heard of users being sent legal letters telling them to stop torrenting copyrighted content. If you're able to mask your IP and tunnel your traffic somewhere else, your ISP should not pick up on it. I'm basically describing a VPN.

    This is the most important step.

    Make sure you configure qBitTorrent to tunnel all your torrenting traffic through a VPN. I have no idea if you can split traffic, but honestly I wouldn't risk leaking traffic. When going into qBitTorrent, make sure to navigate to Tools > Preferences > Advanced. From there, one of the first options lets you choose a network interface. If you are using Mullvad VPN, it should show up as a network interface.

    If you don't do this, you can leak traffic if you turn your VPN off before qBitTorrent, or if there's some I/O error between qBitTorrent and your networking and it just switches to non-VPN networking. This ensures that all traffic goes through your VPN. This also means that if you turn your VPN off while torrenting, qBitTorrent will not be able to access the network because it's restricted to VPN traffic. Sounds simple, but I speak from experience.

    Actually torrenting

    In order to actually torrent, you need a torrent file or a link. This tells the program where the swarm is. I'm providing a torrent file here. It's an album that I made recently, but it's completely free and meant to be distributed via torrent! For qBitTorrent, there's a plus sign in the top left. Once you click that, you can choose a file and start torrenting!

    Make sure to properly configure the path that the torrent/s will be stored. It's easier to keep torrents separate from downloads. Once you're done downloading a file, make sure to keep your program up! You can see what your torrenting ratio is (how much you've contributed back). Different communities can have different guidelines for what an acceptable ratio is. Make sure you figure that out before closing your torrenting program, lest you become a leech.

     

    Preface: I wrote this tutorial for two reasons. More people should learn torrenting, and I want people to listen to my album.

    What is torrenting?

    Torrenting is a distributed file sharing system that basically lets you have really fast upload and download speeds if there's enough people. All the people sharing amongst each other is called a swarm. There's three types of users of a torrent that are commonly referred to: seeds, peers, and leeches.

    Seeds - These are the people that have the whole file and are now sharing it with other people.

    Peers - These are people that are uploading and downloading the file. They have a partial version of the file, but because torrenting shares files in pieces, they can start sharing pieces once they have them.

    Leeches - These are people that download the file and then just turn off their torrenting program and don't share. Don't be these people.

    How to start

    I'd recommend starting with qBitTorrent. It's easy to use, and right now is the gold standard in torrenting software, as far as I know. Additionally, your OS might have an actively maintained package for it, so look for that first! You'll also need a VPN. I'm using Mullvad VPN for this guide.

    Opsec

    One thing to remember about torrenting is that it is a peer to peer network. This means that your computer will be directly connecting to others. Other computers will see the IP address that you're torrenting on. Commonly, ISPs will detect torrenting and I've heard of users being sent legal letters telling them to stop torrenting copyrighted content. If you're able to mask your IP and tunnel your traffic somewhere else, your ISP should not pick up on it. I'm basically describing a VPN.

    This is the most important step.

    Make sure you configure qBitTorrent to tunnel all your torrenting traffic through a VPN. I have no idea if you can split traffic, but honestly I wouldn't risk leaking traffic. When going into qBitTorrent, make sure to navigate to Tools > Preferences > Advanced. From there, one of the first options lets you choose a network interface. If you are using Mullvad VPN, it should show up as a network interface.

    If you don't do this, you can leak traffic if you turn your VPN off before qBitTorrent, or if there's some I/O error between qBitTorrent and your networking and it just switches to non-VPN networking. This ensures that all traffic goes through your VPN. This also means that if you turn your VPN off while torrenting, qBitTorrent will not be able to access the network because it's restricted to VPN traffic. Sounds simple, but I speak from experience.

    Actually torrenting

    In order to actually torrent, you need a torrent file or a link. This tells the program where the swarm is. I'm providing a torrent file here. It's an album that I made recently, but it's completely free and meant to be distributed via torrent! For qBitTorrent, there's a plus sign in the top left. Once you click that, you can choose a file and start torrenting!

    Make sure to properly configure the path that the torrent/s will be stored. It's easier to keep torrents separate from downloads. Once you're done downloading a file, make sure to keep your program up! You can see what your torrenting ratio is (how much you've contributed back). Different communities can have different guidelines for what an acceptable ratio is. Make sure you figure that out before closing your torrenting program, lest you become a leech.

     

    Are there any FOSS alternatives to privacy.com? I want to conceal my actual card information when registering with a new account on different platforms so I can create limits, but I can't shake the feeling that privacy.com probably just sells my transaction history. If there's any alternatives to privacy.com that are more transparent, I'd love to know!

     

    So I've had this idea for an API for a while but the problem I keep coming back to is authentication. I'm using rocket to actually code it. I looked through the rocket docs and it looks like the closest thing to API key authentication it has are cookies.

    I then went and looked at some other APIs to see if I can copy their layouts and it looks like a lot of them use an API key and then a secret API key for authentication. Did some more googling and stackoverflow said that it's more secure to use a pair like that.

    So that leaves me with the actual question: how do you actually implement this feature? Do you just generate API keys and throw them a database to be looked up later? Should they be written/read to a file to be used later(probably not a good option I'd guess).

    Just for reference I'm using rocket, sqlx and postgres.

    view more: next ›