beeboobaa3

[flagged]

sure but politely demanding some documents is not the same as raiding an office

A guess that's probably correct: Many torrent sites (where the client can download .torrent files from when given an URL) their infra sucks. This includes expired certificates. Users don't want to deal with that shit. Developers don't want to deal with users complaining. It's not really considered a risk because lots of those torrent sites (used to) just use HTTP to begin with, so who cares, right?

Let me guess, you're in the US along one of the hardcoded routes?

It can, for plugins. GP is talking about extensions which you typically don't need.

I'm using several maven plugins (not extensions) that are defined within the reactor project itself. It works well.

You do need to split your build into multiple projects governed by a reactor but you'll have that anyway as soon as you have more than 1 module. Then you just always build the reactor. Pretty much the same idea as gradle.

My problem with gradle is that its configuration language is a programming language.

Sounds amazing in practice. And it is. Until you need to fix a 3 year old build that has some insane wizardry going on.

What? I never said being computer illiterate is bad. Plenty of fine people are computer illiterate. And plenty of fine people are fantastic at things I'll never be good at. That's fine.

It allows it's users to actually use their computer as a computer instead of a glorified phone.

MacOS nannies you left and right, preventing you from doing things you want to do because Apple says no.

Windows historically didn't have such restrictions because it's a desktop operating system and not a gimped phone. They're slowly being added, but it takes time to overhaul an entire architecture while maintaining backwards compatibility (which MacOS also doesn't care about at all).

Linux is of course far more "hackable" but there aren't as many computer illiterates using it.

I mean in total it's like 10-30 lines of code put in the place where you load the user session, and a very small rearchitecture of the database.

So... Kind of, yeah.

Each user gets a token associated with them. On each request you first check if they are authenticated via your auth of choice. If so, you take the token associated with this auth from your database. If not, you take the token sent via cookie. If no token is available, you generate one and set it.

Then when a user "signs up" you do the same thing. If they sent a token via cookie, you associate this token with their auth in your database. If they somehow didn't have a token yet they were probably blocking cookies, but you can just generate a new one at that point.

If a user logs in again later while they already had a token you can choose to migrate all data from that token to their login token, so no data that was created prior to login gets lost.

The point is that there's essentially no difference between regular profiles and shadow profiles. Both are just profiles. And a profile can be authenticated with using its token, or using an associated auth provider.