Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[flac.rules]

Is it the designed behavior that the authenticate token changes every time MC restarts? This makes MCWS-commands almost impossible to use for web-commands in a lot of circumstances when you have a user and a password (which is necessary for client to send tag change updates to server). If this i designed behavior, is it possible to turn off?

[Hendrik]

The tokens expire eventually, but not on a restart. I believe its two days or so?
When you keep using them, their timeout is refreshed too, so any active usage does not expire them.

Its easy enough to handle a expire case anyway, if you get a access denied message, just request a new token with the Authenticate MCWS command, and re-send the original command.

Expiration is intended of course, and I don't think an option would be a good idea.

[flac.rules]

The tokens expire eventually, but not on a restart. I believe its two days or so?
When you keep using them, their timeout is refreshed too, so any active usage does not expire them.

Its easy enough to handle a expire case anyway, if you get a access denied message, just request a new token with the Authenticate MCWS command, and re-send the original command.

Expiration is intended of course, and I don't think an option would be a good idea.

Ok, i guess i could somehow force a refresh every night, but that is not a great solution.

It is not that easy to handle, with a lot of setups, just sending a web-command is trivial, reading back the response, then sending the authenticate command, storing it in a variable, changing the string sent with the webcommand. This is a non-trivial amount of work. Especially if the command is not sent from a regular computer.

I think a better idea would be an option to let clients use library sync without a password (at least on the same LAN), i don't need any security when it comes to this, i suspect i am not alone, and this will solve the authentication problems to.

[rlebrette]

Ok, i guess i could somehow force a refresh every night, but that is not a great solution.

It is not that easy to handle, with a lot of setups, just sending a web-command is trivial, reading back the response, then sending the authenticate command, storing it in a variable, changing the string sent with the webcommand. This is a non-trivial amount of work. Especially if the command is not sent from a regular computer.

I think a better idea would be an option to let clients use library sync without a password (at least on the same LAN), i don't need any security when it comes to this, i suspect i am not alone, and this will solve the authentication problems to.

The token is not an API key like the one you can have with IMDB or RottenTomatoes. It's something to avoid basic authentication for each new call.
Since you're in your own lan, you can always run any of the command by sending credentials in the URL:

http://user:password@your_mc_host:52199/MCWS...

This doesn't not require any token.

[flac.rules]

The token is not an API key like the one you can have with IMDB or RottenTomatoes. It's something to avoid basic authentication for each new call.
Since you're in your own lan, you can always run any of the command by sending credentials in the URL:

http://user:password@your_mc_host:52199/MCWS...

This doesn't not require any token.

Thanks, that works I will be using that method.