Service String Ready to Go

The service string is now implemented.  If you include somethink like s:email@example.com, any errors that occur during the request will be emailed to this address.  

census.daybreakgames.com/s:email@example.com/json/get/eq2/character/?c:limit=1

We now have the ability to register keys so that we can define a number of email addresses.  It can also allow us to track requests from each of you and provide some metrics back to you.  Since the requests may be embedded on a client page (using AJAX), you may not be able to track this yourself.

-dan

 

To extend this a bit more, we are going to do the following with the following:

• If you have a service string that is an email address, errors will be mailed to that email address
• If you have a service string that is a registered name, we will look up the email address(es) associated with that name (if available) and send you the error information
• If you do not have a service string, we will output error information back in the response.

This should help you debug your use of the API.

-dan

 

I would be somewhat concerned that as long as I can construct a URL such that it always returns an error, I can now use the data server as a redirector/amplifier for a denial of service attack against the email address of my choice by embedding that URL as the payload of the javascript exploit of my choice.

Having it only email registered emails associated with an account is slightly safer (limits the scope of the damage, at least I can't email [url="mailtoresident@whitehouse.gov">president@whitehouse.gov[/url] that way), though there's no assurance it's *my* account.

 

That is a risk...one we will be monitoring closely.  If this becomes a problem, I will shut it down immediately.  If it becomes a widespread problem, additional controls and policies may have to be put into place.

Since this service went live over a year ago, we have been getting email notifications on every exception.  Every time you see a "Whoa...how did you get here" message, we get a note.  When you are alerted through this mechanism, we are also included.

If someone uses this service to facilitate a DoS attack, it will be a violation of the data policy and the terms of service.

-dan

 

I share Grue's concern there.  IMHO, the best way to mitigate this is to only accept registered identifiers, and reject direct email addresses.  That way, only addressed that are registered with SOE will actually be vulnerable to such an attack vector.  Since the mechanic is already in place for such a registration system, it would be a protection simple to implement.

I'm sure SOE can do some very basic checks when registering an email address - they would obviously be able to refuse registering [url="mailto:jsmedley@soe.com">jsmedley@soe.com[/url] to avoid this being used to mailbomb the poor man whenever someone is disgruntled at the fact that EQ2Players isn't back online yet 

 

Concern noted.  We've just removed support for specifying an email address as the service identifier.  You must register.

This is mitigated by the fact that errors are now put into the results.  As a developer, you'll see the error directly in the returned results (instead of a "whoa...").

-dan

 

Awesome.

Taking into account my day job, but on a more practical level, my role as a amateur Web applications developer, thinking about how you can use a feature is sometimes not nearly as interesting (or chilling) as how you can misuse it. <img src="/station/images/smilies/908627bbe5e9f6a080977db8c365caff.gif" border="0" />

It's the off-nominals that are the really difficult aspects of web application design, IMO... Never trust external input! Not for a second!

 

I have a question...  Since RosterMaster is actually installed on multiple sites by their users, I don't necessarily want all error reports to be mailed back to me - for example if an API change breaks my application, I don't want to get emailed by every single site that uses it  My current plan is to only use the string when the user enables debug mode.

However you are talking about metrics, which I assume means you might eventually consider going beyond just error reports (either for devs or for your own internal management/troubleshooting).  Would it be a problem if I were to pass an unregistered string by default, just for (future?) tracking purposes?  Debug mode would switch to the registered string, so I could get the error reports.

Dark_Grue: Just for the record, I'm going to register "rostermasterSA" here for debugging purposes, will go with rostermasterSAprod for the separate unregistered string (if that's OK with SOE).

 

I am still thinking about how to do the metrics.  Let me get back to you with a proposal.

You'd be surprised how infrequent the errors can be.  If someone is intentionally generating errors, then we'll start clamping down on things.  My email gets every error.  This is very problematic when we get an infrastructure error (database server goes sideways), but it is very reasonable normally.

-dan