|
I am thinking of the possibility of writing a small app that would be of help to Pathfinder Society Organizers. I envisage a system where by the organizer could enter the society numbers of the confirmed players, and the app would spit back a list of characters and what tier they are in, and possibly then sort them into tables.
Ideally this would take into account what scenarios each character had played, and so make sure that they didn't get put down to repeat.
In order to do that though, I'd need a bit of info.
Ideally I would be able to look up a page, say "http://paizo.com/characters/<pfsnumber>" and be given back either a HTML, or XML or something page with Character name, and a list of scenarios applied to that character.
Would that be possible? Is it already possible and I'm just too dense to see it?
Guys, we don't currently have a publically facing API for this sort of information. There are privacy concerns involved and we would have to carefully manage any information we distributed so widely. Not saying we never will provide at least some of this programmatically, but its something we need to think about and plan carefully first.
|
|
Funny, I was just about to ask this question. An API for basic PFS info would be nice; I would LOVE to have access to some basic PFS information, such as which scenarios a player/character number has played/GMd.
On the flip side of this question, does Paizo have a stance on scraping or otherwise tracking this data?
|
Guys, we don't currently have a publically facing API for this sort of information. There are privacy concerns involved and we would have to carefully manage any information we distributed so widely. Not saying we never will provide at least some of this programmatically, but its something we need to think about and plan carefully first.
Sorry for necro, but do you have any public API at all? Or "this sort of information" is about all information?
Guys, we don't currently have a publically facing API for this sort of information. There are privacy concerns involved and we would have to carefully manage any information we distributed so widely. Not saying we never will provide at least some of this programmatically, but its something we need to think about and plan carefully first.Sorry for necro, but do you have any public API at all?
Short of our RSS feeds for some portions of the site, no.
|
The problem is not every game is reported and some games are reported inaccurately. My brother tried to get one game corrected to the correct character and used their link to point out the mistake and nothing ever happened.
For coordinating games at my local gaming store, I created a program that parses the html of Paizo's sessions pages (player sessions, GM sessions and event sessions). I let the players know if they want me to use their games played elsewhere in consideration for what we run in the future they need to just log in, go to their player and gm sessions page. Expand both then save the html as a complete html file and give me their file.
Personally I would have issues if paizo made this information publicly available to people not involved in reporting games.
It parses it and inserts their data into my database and thus I now have a current list of every scenario players have played or gm'd as it has been reported.
I am not sure I could legally give this program out so please don't ask. There are terms in the program that may fall under Paizo's intellectual property and may not fall under their community use policy. I am not willing to hire a lawyer to consult me for a program I cannot make any money off of either because of my contract with my current employer.
I wrote this program to learn more about various concepts that I used in the implementation.
Guys, we don't currently have a publically facing API for this sort of information. There are privacy concerns involved and we would have to carefully manage any information we distributed so widely. Not saying we never will provide at least some of this programmatically, but its something we need to think about and plan carefully first.Cort, I think I've got a handle on some of the privacy concerns and some notions how they could be constructively addressed; I'd love a chance to kick around fan site integration API concerns and approaches as a PaizoCon session and think there'd be some others interested. (If not as a session, a bull session where I'm buying the dev team that's interested in the conversation beers or libations of choice is also an answer that'd please me...)
Any chance that such a conversation could be had?
A formal session might be a little premature, but I'm happy to chat with folks about it at the con. Fair warning, we have a big infrastructure project that would have to be completed before we could consider adding this, but never hurts to talk and get an idea of what sort of data folks are looking for.
Track me down at the con (preferably when I'm not working the register :).
| 2 people marked this as a favorite. |
Great, now I want hot wings.
Me too!
| 1 person marked this as a favorite. |
Bleugh, don't like hotwings, guess I'll be eating croquet mallets.
| 3 people marked this as a favorite. |
Bleugh, don't like hotwings, guess I'll be eating croquet mallets.
I'd suggest going with croquettes instead. Much tastier, though croquets probably have a higher fiber content.
In browsing this thread, I'm hearing that there is "a large infrastructure" project going on that would preclude any API being built and "privacy concerns" related to giving out PFS information through an API.
An API exposing scenarios played/gmed by a given PFS ID# could not possibly have any privacy concerns, could it? I mean ... there is no personally identifying information in such a request and return and no 'sensitive' information regardless of whether identity is known or not ... a structure similar to:
/pfs/user/{pfs_id}/scenarios
... could give a JSON return similar to:
{ pfs_id: {
scenario_id: {
played: true/false
gmed: true/false
}
}
}
... and having that info would be a TREMENDOUS boon to schedulers and players alike. Imagine going to your online scheduling app and looking to select scenarios based on how many of your players have participated already ... so you know which scenarios to schedule and which not ...
... then imagine players being able to go register for these games and being able to know without referencing an easily lost paper which games they've already played or GM'd?
And the privacy concern? None.
There is also a reliability issue. I know I have sessions that were never reported. Most(Many?) players probably eventually end up with at least one. A con session that never got reported. A GM that isn't organized, or just lazy. The system not letting you report a particular character. Lot's of reasons.
I've also got at least a couple chronicles that were reported to the wrong id. I report them when I notice, but I don't spend time auditing the online reporting. I make sure my paper chronicles are organized and keep a list of what I've played. That covers me.
YOU see no privacy concern.... that doesn't mean that there isn't one to be held.
You are correct, I do not see one. If you do see one, could you please enlighten me so that I do not sit here in ignorance?
|
|
It doesn't really matter if any of us see privacy concerns; it only matters if Paizo sees any. They know the inner workings of their (custom coded) system and they may be reluctant to open themselves up to potential IS security problems that an API could bring. If customer data were compromised in any way, they would be on the hook to deal with the fallout. My guess is that in the risk/reward analysis, an API comes out way heavy on the risk side and light on reward.
Personally, I dont want Paizo allowing access to any of my information and I'd be disappointed if they were to allow it.
-Skeld
|
|
I'm going to bring this up rather then creating aa new thread.
it's now been 18 months and to my knowlege there hasent been any movement aor discussion on this.
something like the json api noted above that just gives a pfs number (so no name or email etc details) and a list of the scenarios they have played (and preferably run but thats less important) would allow us to expand the current pfs tools significantly and eaase the growing burden on even orginizers trying to schedule tables for local events
There's already the concept of "Partner Authorizations" with accounts under My Account. I don't much see a reason that concept couldn't be expanded. Give folks a simple interface to generate or revoke an API token and a simple checklist of things their token returns.
I'd wager this has more to do with the corporate strategy side of things or potential concerns about data mining. If only there were the concept of Universally Unique IDentitiers that made such data mining almost impossible leaving the corporate strategy bit. They simply don't want to, mate. ;)
At this point, there are no plans for public-facing API projects. The Tech Team still has quite the backlog :)
|
I'd wager this has more to do with the corporate strategy side of things or potential concerns about data mining. If only there were the concept of Universally Unique IDentitiers that made such data mining almost impossible leaving the corporate strategy bit. They simply don't want to, mate. ;)
You also need to remember, that the fundimental design of the site is that the same account is used for the messageboard, store, and PFS. So anything that gives access to one needs to ensure there is no backdoor vulnerability to the others. especially when credit cards and shipping addresses are involved. Similarly, allowing people to see what they have supposedly played, but not where seems counter productive, especially if someone memorized their number wrong and has been giving the incorrect number out for 2 years, and oyou have a ton of sessions that you never played associated to the account. But providing where you've played (even game day titles) to everyone allows someone to track your movements (albeit on a limited basis). Also of note is the user agreement when you log on... I've been on the boards for a long time, but I'm pretty sure there is a whole privacy section in there with what they can and cannot provide.
You also need to remember, that the fundimental design of the site is that the same account is used for the messageboard, store, and PFS. So anything that gives access to one needs to ensure there is no backdoor vulnerability to the others. especially when credit cards and shipping addresses are involved.
This isn't nearly as hard as you might think it is. It's called a parameterized query and they've been around for ages now. Also, backdoors aren't stumbled upon. They're installed. If you don't want backdoors then don't put any there. If you're thinking about security vulnerabilities (they're different), nothing is going to change the form of the data being queried because we parameterize queries in any sane application. Paizo has done and said some things that makes me question their environment, but I can't fathom them being that messy. That would be downright unprofessional and negligent of them. If their servers were already breached in a manner where an attacker could change the data being queried, then they already have all that data and probably more. A public API wouldn't be the weak point.
Similarly, allowing people to see what they have supposedly played, but not where seems counter productive
I don't think so at all. I know people who jump on online sessions and physical ones all the time, VCs and VLs most commonly. It doesn't matter where you played, just that you got credit for the scenario.
Also of note is the user agreement when you log on... I've been on the boards for a long time, but I'm pretty sure there is a whole privacy section in there with what they can and cannot provide.
So update the privacy policy. Companies do it all the freaking time. Then, move the onus on privacy onto the user by way of what they choose to share. That's another thing companies do all the time.
So, to play privacy devil's advocate for a moment. Say an API is provided that allows me to specify a PFS ID and get back a list of played scenarios, with a core/non-core flag and a date. Nothing more.
With just that API, I could harvest a complete picture of who played what and when. Complete. Call for pfs_id=1 through pfs_id=300000. I then dump this data into my own DB and begin mining it.
I can soon learn who plays with whom, regularly. I can derive who is dependent on whom to play. For example, my daughter almost never plays without me being at the same event. I can find relationships like that from the "simple" API defined above.
Now, I can try to identify possible minor's IDs by playing with the registration system. Soon I have a list of PFS IDs of possible minors and a decent idea of their schedules at a FLGS.
I won't continue, but there are approaches to determine where these people play.
Eventually, I can figure out who tends to play with the whole family and will therefore be out of their home for 4-6 hours on a regular basis.
Now do you see why Paizo is hesitant to facilitate this data mining? And I haven't even mentioned the potential value to competitors.
All of this works even though there are absolutely no security vulnerabilities in Paizo's code.
|
|
GinoA, I think your overstating this, and/or assuming a lot more data them I'm looking for.
if the data is simply put in a PFS number, get a list of scenarios and the core/rpg flag and a Gm flag there is no data to tell where or when a given scenario was played. So correlating PFS numbers like your suggesting would be impossible, the data would just not be there. and to be honest for the purpose of what this would be, there is no reason to give more data then that.
You would know who has played the same scenario, but there would be thousands of people that have played any given scenario, so finding two people that have played together without some additional outside information (i.e. you go to sessions with them, and there fore would already know what your looking for)
I'm not asking for an API that can write to the Paizo database, I don't think there is any legitimate use case for that, I'm just looking for something that can be used for scenario tracking and event planning.
While I understand the tech team is busy, It should not be to hard to write a simple script to query the database and format this small amount of data.
Not to mention no sane API would simply take a PFS number as the identifier. The identifier the API would take in would look something like 123e4567-e89b-12d3-a456-426655440000. This token would then return you whatever information that user has configured to share through this non-existent API from their respective My Account section on this site, anything from their PFS number to scenarios played or whatever else might in it.
Also, yes, while sequential UUIDs are a thing, you would not use them for something like this. They would be randomly assigned. One of the strengths of many UUID implementations is that you could keep guessing them for thousands of years (literally) and never get the same twice since they're 128 bit numbers. To quote the wikipedia article on UUIDs...
In other words, only after generating 1 billion UUIDs every second for the next 100 years, the probability of creating just one duplicate would be about 50%.
This is why they're often used in APIs such as this. They both uniquely identify resources and are hella hard to guess and anticipate. What's more, the algorithm for creating a random UUID are super common and in many, many APIs. They're standard. It's not something Paizo would have to invent. For example, in .Net it's literally as simple as calling Guid.NewGuid(). Done.
The tricky part comes in access and sharing these IDs. This is usually through a sort of verification. So, you would likely sign in with your Paizo credentials letting them keep a consistent log of API requests made from your account. This would issue you a temporary authorization token letting you make API requests and let you enter a PFS number most likely for ease of use, which would then return the UUID of that PFS number. You could then call their API with that UUID, bundled with your temporary token that ties to your account, and a public token granted by the owner of the PFS number which would get you the information you're going after. The awesome part of this is that the vast majority of it can be automated on Paizo's side. Plus, if there were some creepy stalker person, Paizo would see these vast number of requests quite easily. You could also see who requested information about you. This stuff isn't hard.
|
|
Buri,
I'm genuinely curious as to why you think something like a new unique identifier would be needed for this sort of api?
You give out your PFS# at every game you play so its not like its some sort of secret, and linking the scenarios that have been played to a PFS number is not something huge either.
I agree that giving more then that can potentially have security implications, but no one has ever asked for that.
we literally want an API given a PFS number spits out something like
{PFS_ID {
scenario_id: {
played: true/false
gmed: true/false
core: true/false
}
}
Now if you can come up with any way I can link a bunch of records with nothing but those fields together to cause even the slightest hint of an issue for a person I would love to hear it, short of getting extra data from somewhere.
if you want a more comprehensive API that people can allow access to with some sort of key (that may contain data like there paizo username for the forums, event and date information for scenarios etc) then that would be cool, and I agree with the opt-in approach to that
The reason is because of a general guideline. You never take in meaningful data from a public facing, unauthenticated endpoint. You take in meaningless data (as far as the outside world is concerned) and see if it has a mapping on your system.
So, an obvious example is that you'd never take in a social security number on an open, unsecured channel. If you had an unsecured API that sent/received SSNs at all, you'd be dumb. But anyway. You would instead take in some sort of unique identifier for the record that represents the record containing the SSN. You'd use that identifier to look up the record and return the SSN.
sure that makes sense in the case of a SSN, but aren't our PFS numbers already that in this case?
they are already a meaningless identifier for our paizo accounts, and that is the real information that needs protecting here.
You and I identify meaningless in different ways, apparently. Meaningless is something that is useless on its own. It identifies no one and nothing. It indicates no status. It has zero significance. A PFS number is the exact opposite of those things.
|
|
Getting back to the original topic, let's imagine for a moment that there were a browser extension that allowed you to export your PFS session information, and a corresponding site where you could import it, determine sharing settings, and view others' public data.
Would that solve the problem that those of you who've requested this feature are trying to solve? If not, what's missing?
not really Oaldon, that's still reliant on someone to update there information, its a manual process that most people wont do, so event organizers wont have the information they are after to be able to schedule events for the maximum amount of players without putting every scenario on offer every game day.
the point is to give an interface that dosent rely on a player doing anything to give you accurate information to schedule off. I know not everything gets reported, but its a hell of a lot better then what we have now.
you and I identify meaningless in different ways, apparently. Meaningless is something that is useless on its own. It identifies no one and nothing. It indicates no status. It has zero significance. A PFS number is the exact opposite of those things.
I'm not sure what you mean by this, a number doesn't identify me any more then a UUID would (unless you already know something about that link) my PFS number is meaningless on its own, it has no status.
sure in the edge case, someone who has won a campaign service award might be able to be linked to a specific number, but the easy option for this is only to allow there original numbers not the new 3 digit number to be used for the API.
The ONLY thing you can do with a PFS number is report a session as having been played/GM'ed by that person, and knowing the scenarios that number has played is not going to make any difference to being able to do that, I could go in right now and report 100 tables with random PFS numbers, there is nothing to stop me, and knowing the scenarios they have played/run is not going to change that fact.
if you have some other way a PFS number can be used that I haven't thought of, please let me know, but I can't see any.
PFS number 72364 (random key press) indicates a player. PFS number 72364_1 indicates a character. Plus, they're sequential and therefore easily guessable. There's a ton of implicit meaning in PFS numbers.
I'm the one that highlighted the fact they didn't want to do it in face of their very PC responses prior to Chris' post. ;) This is just discussion now.
|
|
it would be useful to event organizers and by extension players as its easier to find games they can play.
the problem i see is getting enough users to make it worth while, the same issue every other tracking method seems to have, hence the request for an API to let us get it without player intervention.
Even a simple API that had nothing to do with players would be useful.
For example, a set of API endpoints that returns a list of all sanctioned scenarios, tiers and sub-tiers, and which are evergreen, and other sanctioned content modules/paths/etc., and their associated information.
Or perhaps an API that lists shipping PF products, current prices, release dates, etc.?
Could be, yup. Also, they're not hard to setup. You can have a basic API up and running in a day.