Script Rules Revision

[Eluvatar]

Following a recent incident, Admin attention has been drawn to the Script Rules not requiring a User Agent for non-API requests, which is if anything more helpful with tracking non-API script usage than API script usage.

The below section has therefore been added to the Script Rules, bringing them into line with the API terms of use.

User Agent

You must set your script's UserAgent to something informative, such as the URL of your site. This allows us to contact you if something goes wrong with your script.

[Caelapes]

What about client-side scripts that change the look or functionality of a page through Javascript? Should useragents be set for these?

[Leppikania]

What about client-side scripts that change the look or functionality of a page through Javascript? Should useragents be set for these?

Those would already set user agents, because the script is bound to the web browser.

[Eluvatar]

What about client-side scripts that change the look or functionality of a page through Javascript? Should useragents be set for these?

If your script does not make http requests of nationstates.net, it does not need to set a User Agent.

If your script is completely unable to set a User Agent, it needs to identify itself in some other manner, like in the below example for googlescripts:

I'm updating all the active gdocs I have edit privileges in to add the below to all API request URLs:

Code: Select all

"&gdoc="+SpreadsheetApp.getActiveSpreadsheet().getId()+"&useremail="+Session.getUser().getUserLoginId()

Because getUserLoginId() is being deprecated I would suggest changing the above code to something like:

Code: Select all

  var url = "http://www.nationstates.net/cgi-bin/api.cgi?param_name1=" + param_value1
    + ...
    + "&gdoc=" + SpreadsheetApp.getActiveSpreadsheet().getId() + "&useremail="
    + Session.getUser().getEmail();

For scripts triggered by anonymous user action, I would suggest either not having them, or substituting the sheet owner's email instead:

Code: Select all

  var url = "http://www.nationstates.net/cgi-bin/api.cgi?param_name1=" + param_value1
    + ...
    + "&gdoc=" + SpreadsheetApp.getActiveSpreadsheet().getId() + "&owneremail="
    + SpreadsheetApp.getActiveSpreadsheet().getOwner().getEmail();

What about client-side scripts that change the look or functionality of a page through Javascript? Should useragents be set for these?

Those would already set user agents, because the script is bound to the web browser.

A generic user-agent is inadequate. The point of the rule is to require scripts to identify themselves.

[Caelapes]

What about client-side scripts that change the look or functionality of a page through Javascript? Should useragents be set for these?

If your script does not make http requests of nationstates.net, it does not need to set a User Agent.

It does not make an HTTP request. It uses Javascript to, at the script-legal rate of one click per action, activates a button on the NationStates page (e.g. like an RMB post, unsuppress an RMB post, etc.). What is the preferred method to ensure these types of scripts are fully script-legal with this revision?

[Eluvatar]

If your script does not make http requests of nationstates.net, it does not need to set a User Agent.

It does not make an HTTP request. It uses Javascript to, at the script-legal rate of one click per action, activates a button on the NationStates page (e.g. like an RMB post, unsuppress an RMB post, etc.). What is the preferred method to ensure these types of scripts are fully script-legal with this revision?

Two things.

Firstly, the script you are describing (in somewhat more detail in other contexts) could easily run afoul of this rule:

A tool may never execute restricted actions simultaneously. It must wait for the completion of each command--a complete response from the NationStates server--before issuing the next one. A tool should never spawn background processes to enable multiple simultaneous server connections that each perform a restricted action.

Your button should not cause anything to happen until the previous thing has completed.

Secondly, in such a case you are not required to set a User Agent. It is, after all, impossible.

You should however add a field of this form to the parameters: script=An%20identifying%20string
While this may not be required in this particular edge case, it may soon be, and it's helpful to admin in general.

Since you can't legally just call click() on the other buttons you want to click as that doesn't prevent simultaneous requests (which are illegal for a tool to execute) this isn't much extra work regardless.

[Tim-Opolis]

Quick question, would our NS Nation be fine as a useragent or would you prefer an e-mail or some other way of contact. I've been just using Tim-Opolis as my useragent on Auralia's Auto-Login Interface, but can certainly change that to say " Tim-Opolis | "myemail" " if that is preferable for the administrative team.

Thanks!

[Eluvatar]

Quick question, would our NS Nation be fine as a useragent or would you prefer an e-mail or some other way of contact. I've been just using Tim-Opolis as my useragent on Auralia's Auto-Login Interface, but can certainly change that to say " Tim-Opolis | "myemail" " if that is preferable for the administrative team.

Thanks!

Yes, so long as your nation has an email you regularly check set and/or you check your nation's telegrams regularly.

Regarding the aforementioned simultaneity rule, I've composed a post seeking to help people comply with it.

[Aptenia]

There should be a new notice in the News section that directs questions here