Welcome to Microsoft’s co-pilot dream.

We’re glad you are here!

According to the Google Play Store, there are 467 reviews (4.8 stars) but “0+” downloads. Like everything else about the White House, it doesn’t add up.

And maybe most people know to keep it off their phones.

Is this only for people using Garmen Connect or something else?

By any chance are you using NoScript or some other extension that is blocking the JavaScript from the site?

Sigh. Yeah, that’s not right to get banned for having a different opinion than a moderator.

You really were banned on other instances for saying marijuana use should be strictly regulated?

You are asking a reasonable question that many ask.

Each account will be a unique and separate account on each instance. Instances do not share accounts.

Although you can, on some applications, authenticate with a federated account, like Google or even a Mastodon account, you still will have an entirely different account on the server.

Oh. You’re right. Well, the rest of the article is a good read. I’ll update the headline. Thanks!

Wine requires Linux knowledge to get the configurations correct. I don’t think many Windows users will be able to get any Windows applications running under Wine. And it’s the same Wine that any Linux user can install for free.

If Zorin came packaged with Crossover, then maybe it would run Windows apps better because Crossover would manage the Wine configurations and the required Windows infrastructure installs.

Maybe.

But not many old machines will have the capacity to run Linux, Wine, and a Windows application. But Zorin’s hype leads one to believe that a 15-year-old machine won’t struggle.

I tried it about a month ago and found it had nothing more than what you get with an Ubuntu install, save for the look of the screen. I couldn’t understand why the media was making a big deal about it. And I saw no reason why anyone should pay for Pro. My conclusions matched what is in the article.

The headline of this post is technically accurate but purposely provocative. The article’s headline is more informative: " Fake 7-Zip downloads are turning home PCs into proxy nodes".

The point is that 7zip.com is not the official website, and this is where many people are going for it, and getting malware.

@rimu@piefed.social
But the logins from Voyager are returning 400 (Bad Request), although the username and password are correct, and to me, the request looks good.

I posted what is coming into the server. The only anomaly I saw was that the session cookie referrer seemed odd. Can you look at the request I posted? Do you see any reason it would be seen as a bad request?

The odd thing is that while I get an error 95% of the time trying to log into Voyager, twice it did let me log in. I don’t know what was different about those 2 times.

Nothing gets logged to syslog, any nginx logs, pyfedi.log, or journalctl.

Nope. I posted below what is coming into the server. The only thing I can think of is that the referrer is coming in as https://localhost/inbox which might explain the 400 error (Bad Request). Does your nginx configuration drop incoming cookies for the login endpoint?

Help me here. I’m not an expert. Here is the request going into the server. The error code is 400 (Bad Request)

@x..@x..  
18:24:10.580462 IP 127.0.0.1.49126 > 127.0.0.1.5000: Flags [P.], seq 5107:5771, ack 1755, win 8143, options [nop,nop,TS val 1081650450 ecr 1081650382], length 664  
E....3@.@...............kz.....n...........  
@x..@x..POST /api/alpha/user/login HTTP/1.1  
X-Forwarded-For: 162.120.199.186, 172.70.111.121  
X-Forwarded-Proto: https  
Host: feddit.online  
Content-Length: 56  
accept-language: en-US,en;q=0.5  
content-type: application/json  
accept-encoding: gzip, br  
cf-ray: 9c85ae25b9720f65-EWR  
user-agent: Dalvik/2.1.0 (Linux; U; Android 16; Pixel 10 Pro XL Build/BP4A.260105.004.E1)  
cdn-loop: cloudflare; loops=1  
cf-connecting-ip: 162.120.199.186  
cf-ipcountry: US  
cf-visitor: {"scheme":"https"}  
cookie: session=eyJSZWZlcmVyIjoiaHR0cHM6Ly9sb2NhbGhvc3QvaW5ib3giLCJfZnJlc2giOmZhbHNlfQ.aYJgEQ.nMo4SDt0iKOrzFvSItQuquLp4qo  

{"password":"<hidden>","username":"testuser"}  
18:24:10.584409 IP 127.0.0.1.49120 > 127.0.0.1.5000: Flags [P.], seq 8671:10383, ack 2866, win 22123, options [nop,nop,TS val 1081650454 ecr 1081650338], length 1712  
E.....@.@.CB.............BO.+Ngj..Vk.......  

The session string is: eyJSZWZlcmVyIjoiaHR0cHM6Ly9sb2NhbGhvc3QvaW5ib3giLCJfZnJlc2giOmZhbHNlfQ
This decodes to a referrer of: https://localhost/inbox

I wonder if this is the issue. Will Piefed accept a session claiming to be from localhost? Will it see this as a potential attack or misconfiguration? Should I reconfigure nginx to drop incoming cookies for the login endpoint?

I’m grasping at straws.

Very odd thing. Sometimes I am able to log in via Voyager. Mostly not.

At one point I put a space after the user name, and then it logged me in. Once I didn’t, and it logged me in. But it isn’t consistent. The server is complaining that there’s a problem in the request format. i don’t see anything different that allowed the log in those 2 times.

The Cloudflare WAF log shows that it allowed the login request to go through. I’ll have to look more this evening.

deleted by creator

I have to look again because it was a while ago, but I do block some user agent strings, but if I’m blocking Voyager this way, I really screwed up.

Another possibility is that Cloudflare is presenting a managed challenge during sign up.

This is helpful. Thanks.

Can you share the curl command? Seems like something worth keeping in my notes and will help me in looking more closely at the firewall rules.