OpenID in the works?

See, my issue is lets take our site's sigs as one example. We plan on giving outfit leaders the ability to customize their own outfit member's sig options, i.e. when their outfit members join the site, they will have access to outfit specific sig backgrounds (and likely more features later).

Our goal is to have the website be a vital tool in character and outfit management and planning, by providing more extensive reporting such as activity trends, cert and equipment load outs and plans, etc.

As a leadership/tactical type, I can't stress the importance of knowing the strengths and weaknesses of your outfit as a whole for better decision making.

The site could be a potential mess without some sort of validation... we don't need a means to fetch all the user's characters... just the means to verify that the character is indeed that user's, which I think from SOE's perspective, might be a better way to go about this whole thing... and why I suggested changing the call to have a required param of a character ID so on login, it returns true/false on if it's owned by that user or not, instead of returning their whole char list.

 

Jubei - that's more or less the same thing, except to get the same results you'd have to send in multiple requests. 

 

Back before we launched, we thought of a way that we could authenticate users without any assistance from SOE.

1. Create a 20-30 character token that is valid for 15 minutes and only usable once.
2. Have the user login to their game of choice and paste that token into their Biography field. Then have the user zone/camp to force a Census update.
3. Click a link on our fan site that re-loads the character's data and checks for the presence of the token. If it's there, then that person has control over the account and thus has identified themselves. Flag the account as "Verified" and import all the characters currently opted in.

At the time, we only had a couple of ideas for things we could do that would require authentication, so we never went past the concept stage. But for Signatures, Avatars, and other things that a player would like to control about how their characters display, it might be worth the effort on the part of the player.

 

No.. it's not, and here's why.  It still requires you to log into your account at SOE to confirm that that character is indeed yours.  passing multiple character IDs won't do anything except verify if or not those characters belong to that specific user. Basically you are sending a character ID to verify with SOE, SOE asks you to log in, then if there is a match it returns true, otherwise it returns false.  you still have to log in every time.

Sigs and Avatars are the start of what would be player specific... but if you think about a fan site that provides more detailed outfit wide statistical information for example... that gets into the more sensitive side of PlanetSide2 character, outfit, and tactical information.. and so that put together with the prospect of having a web app specifically used for more detailed outfit management and tactical decision making... privacy and user character verification becomes increasingly important..

My dayjob is building and working with APIs (granted mostly for ERP systems), so I've had some time to see what works and what doesn't, granted it always depends on a plethora of factors, am sure here is no different.

I think the current method of retreiving characters of an account could be slighly modified to make both security concerns eased as well as maintain a means for fansites to authenticate their users' requests to link to their game characters.  

See the following methods as a few examples of how it could be structured.

1. fansite asks the users to search for their characters, when a result is returned, user selects their character.  On select of a given character, a link is structured to call the such as users_character/character_id instead of no param the way it is now.  Then the same proccess as it is now is followed, on successful login and cookie set, the users_character option only returns the character authorized in that session.  Any new character authenticaiton requests resets the process and you start over, i.e. log in again (for added security).
2. fansite has a link on a page that opens a new window to SOE.com login specific for users_character API call.  Use the call to users_character to initiate login. On login, ask the user which characters they would like exposed for that session and site (i.e. using the service ID as connection identifier).  Then the rest of this functionality is the same as it is now, except it only displays the one character for that cookie and service id combination.
3. Ideal situation:  This would require replacing the current method entirely as well as change the way the API is used by API users.  All fansites to use the API register as API apps, otherwise they only have access to the public API calls and even at that have a limit on the number of requests they can make in X amount of time (to encourage registring your app if you are going to do more dynamic interactions).  This would allow for API callback URLs to be put in effectively allowing two way communication so things like Token authentication is possible.  Take a look at how facebook, google, and paypal for example do it.  Personally for SOE game characters I would lean to the Facebook model where the App requests specific resources from the user's account/characters and then SOE asks the user "do you want to give this website these permissions?".  This method would allow more effective use of the API in it's current form, adding more secure and reliable tracking of api usage, as well as allow for effective further growth of the API to do things like chat with ingame characters, and character and outfit management tasks if it's decided to add those capabilities to the API.

It's been my experience with such things, pre-thought is better than after-thought..

 

1. This is an unsecure hack.

2. This is even more of an unsecure hack.

3. This whole thread is about (one of) what you suggest: Google = OpenID or OAuth2, Paypal = OpenID, Yahoo = OpenID, Facebook = OAuth2, Twitter = OAuth.  Apps themselves do not register with a service.  The user registers the app to be allowed access to a limited set of their data, specifically only when that user is using the app.  The app cannot make use of the API without the user's interaction, usually a login of some sort.  Example, my site lets users one-click login with OAuth, OAuth2, and OpenID services (I've enabled Facebook, Google, and Yahoo at the moment.)  This lets the user login with their already existing connection to one of those services.   This does not allow me to do anything with that user's account/API Data without interaction from the user while they are logged into that API.  And if you read the Google or Yahoo (both OpenID) prompt that asks the user about allowing the website access, it clearly states what that app is requesting access to just as Facebook does.

Anything outside of OpenID, OAuth, or OAuth2 just will not happen, and even then they still will not likely be allowed.  The first two options you mentioned are horrendous custom hacks that are so open to hacks that it's should not even be brought up.

 

I agree that 1 and 2 are not ideal.  I just put them forward as a 'patch' to the current system in the intrum instead of totally removing it.  i.e. increasing the security of the current system a bit.  Now, if they have the time, desire, and most importantly the priority and OK from management to build out the entire OAuth system then ofcourse that should be the favored route.  I am just taking into consideration here what the devs would pitch to management in terms of how many hours it would take to put something into service compared to its' worth to the entire system.  

You have to look at it from the cost/benefit perspective to understand why i even put up patch jobs to the current system as well as the best solution.  

Now granted I never worked as a dev or in a dev team of SOE's MMO Desktop games, but I am just making the assumption that they will need a quick temp fix and real feature addition to replace the system as options to consider which is better than taking it out completely until if/when they implement OAuth.

 

lol, I started to do that but then I know how 99% of people can't follow simple instructions. I was hoping SOE wold provide a simple way for users to prove that said character was actually theirs.

Now I am just going to go live with my sign site and if people get griefed, it isn't like I didn't try.

 

Well... ended up re-writing the login schema... basically now I have users search for a character they want associated with their login.  I'll have to add later the ability to add multiple characters to their profile though... see the flow here: http://ps2apps.com/register

I just really hope SOE decides to gets OAuth going...