The command line option "--http-password" to allow unrestricted HTTP interface access is broken

changed the description

Works fine here, user syntax error.

I'm typing in exactly what the VLC error is telling me to type in. When I use the command vlc --http-password in a linux terminal I'm getting the error: vlc: unknown option or missing mandatory argument '--http-password'

Exactly what syntax are you using in order to get it to work?

Also, it's not possible to pass an empty string as the username for wget, curl, nginx proxy, or basically any other script/program except a web browser so this renders the HTTP interface for VLC effectively unusable and incompatible with every other tool in existence. You can't even specify an empty username in a url schema like http://:vlcpassword@127.0.0.1:8080/requests/status.xml?command=in_pause (That won't work). So how is a user supposed to use this HTTP interface programmatically? The simple and user friendly solution would be to just add a non-empty username.

Did you even read the error message that you posted? Literally it states "missing mandatory argument".

So first you abuse the bug reporting system to handle a personal user support problem and then you insult the volunteer triaging the report.

Wow. And who's the a--hole exactly?

It goes without saying that you should consider yourself permanently banned.

lol go ahead ban me

continue living in your delusions of grandeur

It has been independently confirmed that I am indeed a volunteer as I believe myself to be. Furthermore the VideoLAN non-profit has no pretense about being a charity, just a non-charity mission-based non-profit organisation. Sorry to shatter your ego self-defense mind construct, but no delusions are involved here.

According to my moral values as well as the VideoLAN code of conduct, insulting volunteers is not acceptable.

I never made any of those accusations.

I think VLC is a wonderful program. My only issue is that that the http authentication is screwed up because the default (and unchangable) username is an empty string. It makes the http interface component practically unusable without jumping through difficult hoops to make some sort of strange work-around. I read the related issues around this matter over the last 8 years. As other users have pointed out, there are plenty of reasons why there SHOULD be a username but in the 8 years this has been discussed, you haven't given a single reason why the authentication SHOULD NOT have no username.

What difficult hoops? Browsers are perfectly fine with this, any sane HTTP protocol implementation should be fine with this, and for scripting purpose curl is also fine with this. Also contrary to your claim, RFC 3986 leaves this entirely manageable with the legacy URL syntax embedding an empty username and a password.

I can't give you a reason why whatever you did does not work since you did not specify what tools you use, and it's most likely not something that I know anyway.

There is no username because it would be an unnecessary hoops for users to set up on top of the password. And, at this point, it would break backward compatibility with existing VLC versions in plenty of existing VLC remote control apps.

I mean the fact that I have to set up a proxy with a service (php's fsockopen function) because MOST services won't allow such a request without a username. Those are the hoops I'm talking about. Here are some specific examples:

curl doesn't work:

$ curl http://192.168.1.105:8080/requests/status.xml?command=in_play&input=/home/sound.mp3 --user ":myvlcpassword"
[1] 20361
<?xml version="1.0" encoding="ascii" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml10/DTD/xhtml10strict.dtd">
<html lang="en">
<head>
<title>Unauthorized</title>
</head>
<body>
<h1>401 Unauthorized (/requests/status.xml)</h1>
<hr />
<a href="http://www.videolan.org">VideoLAN</a>
</body>
</html>
--user: command not found
[1]+  Done                    curl http://192.168.1.105:8080/requests/status.xml?command=in_play

wget doesn't work:

$ wget --password='myvlcpassword' http://192.168.1.105:8080/requests/status.xml?command=in_pause
--2022-07-07 14:55:18--  http://192.168.1.105:8080/requests/status.xml?command=in_pause
Connecting to 192.168.1.105:8080... connected.
HTTP request sent, awaiting response... 401 Unauthorized

Username/Password Authentication Failed.

Twilio has no way to do a GET request with basic http authentication unless you include the user and password into the url.
Attempting to embed an empty username into URL syntax in order to get around the fact that a certain service won't accept an empty username doesn't work in anything either: http://:myvlcpassword@192.168.1.105:8080/requests/status.xml?command=in_pause

I'm sure there are many more examples considering the fact that I'm not the only one who has brought up this issue over the past 8 years.

You bring up a valid point about backwards compatibility. That's obviously very important. So why not allow both an empty username and both a preset non-empty username (such as "vlcuser"). That would fix it right there, be minimal effort, and zero negative side effects as far as I see. Why wouldn't you want to make that change? What is the downside?

--user: command not found

@vmonkey I did not test if it works or not, but at least your url parameter needs quotes (due to the & which is interpreted by the shell):

curl 'http://192.168.1.105:8080/requests/status.xml?command=in_play&input=/home/sound.mp3' --user ":myvlcpassword"

Regards

these 3 commands works for me

curl "http://127.0.0.1:8080/requests/status.xml?command=in_pause"   --user ":lol"
wget -O - --user "" --password "lol" "http://127.0.0.1:8080/requests/status.xml?command=in_pause"
http -a :lol "http://127.0.0.1:8080/requests/status.xml?command=in_pause"

closed

added Component::Interface: HTTP server Status::works for me labels

There is a username, which just happens to be the empty string. This is permitted by the RFCs.

The command line option "--http-password" to allow unrestricted HTTP interface access is broken

Child items ...

Activity