Lisa
Well-known member
I would say not putting it in your signature would be more secure too
License Validation API
- Thread starter Mike
- Start date
I would say not putting it in your signature would be more secure too
Heh that was an extreme example but I was thinking more what happens if one of the developers keeps a big list which they lose or accidentally distributed. I can imagine that'd end up on one of the warez forums.
Regenerating each time should be heavily recommended if not forced.
jmurrayhead
Well-known member
I'm sure the API will be expanded upon over time. This is a great start.
That still wouldn't help if I only ever generated one token to give to one developer to purchase a single add-on.
It is up the license holder to confirm the token check has been done and then to generate a new one.
That way any lists which are kept are worthless.
One-time tokens would be a pain because if I wanted to approach multiple developers for work I'd have to give them the same token, because when I generate the second one the previous one will be invalid, meaning the developers won't have a valid link.
I'll rephrase it to "regenerate after each use" rather than "regenerate each time"
Sorry don't get me wrong, I think this is superb but I just think some advice along the lines of exactly what you state, "confirm the token check has been done and then generate a new one" should be stated somewhere on the page, not buried in this thread.
And if you give the same token to more than one person?I'll rephrase it to "regenerate after each use" rather than "regenerate each time"
Surely it's just common sense?
Well, there's always going to be a challenge here, but I would probably recommend that devs only accept a token once (or once per customer, depending on your structure). I'd probably recommend checking the token periodically, though obviously regeneration will break that (by design - that's what it's supposed to do). The dev would have the option of ensuring that you always kept an up to date token with them.
If devs want to maintain blacklists based on customers tokens/license tokens, then obviously that's their option, so it does open up the risk of someone impersonating you.
From the perspective of giving it to add-on devs, I'd probably keep the token private. If you can't trust someone with that key, how can you trust them giving you arbitrary code to run?
From the perspective of selling a license, the token won't survive the sale (and even if it did, it wouldn't be transferrable any more at least).
If devs want to maintain blacklists based on customers tokens/license tokens, then obviously that's their option, so it does open up the risk of someone impersonating you.
From the perspective of giving it to add-on devs, I'd probably keep the token private. If you can't trust someone with that key, how can you trust them giving you arbitrary code to run?
From the perspective of selling a license, the token won't survive the sale (and even if it did, it wouldn't be transferrable any more at least).
Obviously, there are also alternatives that start to get into OAuth, but I don't think they're particularly useful here mostly because of the implementation overhead. If the sites in question (add-on devs and secondhand sales) don't use the API, it ends up being useless. Having to implement a whole 3 legged OAuth type system to do that is probably out of the scope for most people.
Shelley
Well-known member
I think it's a perfect solution. Try getting support for 3rd party vendors like this any where else...it doesn't exist.
Very true John. I'm quite shocked (in a good way) this even exists, was developed. Certainly another first from Xenforo.
Reeve of Shinra
Well-known member
I think this is a really good move for the dev community.
Thank you, as always, for listening to us and acting on the feedback.
Thank you, as always, for listening to us and acting on the feedback.
Ok, I'll rephrase it to "regenerate after you've confirmed the token is no longer required by the developer(s)". That's getting into semantics now and all I mean is some advice not to leave a token "active" for months after it's not needed would be useful for people.
You've just said it yourself in this thread that "It is up the license holder to confirm the token check has been done and then to generate a new one." which is exactly what I'm advocating that you make clearer
So I've made some tweaks here: http://xenforo.com/api/
I've added a mention of regenerating tokens if you wish, but that there's a trade off. I've added a clarification of expectations if you ask for tokens from people. I've also added a set of best practices.
One of the key best practice options involves asking the person supplying you with a token to put something on the domain that matches the token, like Google Webmaster Tools. You can use this to verify that the token actually belongs to them. Obviously, it's up to people to implement that step though.
I've added a mention of regenerating tokens if you wish, but that there's a trade off. I've added a clarification of expectations if you ask for tokens from people. I've also added a set of best practices.
One of the key best practice options involves asking the person supplying you with a token to put something on the domain that matches the token, like Google Webmaster Tools. You can use this to verify that the token actually belongs to them. Obviously, it's up to people to implement that step though.
Oh, I forgot to mention that I added a "license token" (different from the validation token) that uniquely identifies a license across validation tokens. So a dev could store that rather than the validation token and simply check that subsequent calls match that (if they desire to attach things to a particular license).
jmurrayhead
Well-known member
Typo: change 'a' to 'at': The request period restarts at midnight GMT.
Similar threads
- Locked
