chore: disable ARRAffinity cookie

[keymanapp]

chore: disable ARRAffinity cookie

[mcdurdin]

We do not use ARR at present -- and are completely stateless should be able to disable it per https://azure.microsoft.com/en-us/blog/disabling-arrs-instance-affinity-in-windows-azure-web-sites/

We can move this issue to api.keyman.com to be addressed there.

[jahorton]

a link to the site where this was happening.

I believe this was happening for in-repo pages under web/testing. I'm not 100% sure on whether it involved localhost mode or file:/// mode, but it was reported for one of those two hosting patterns for pages.

[jahorton]

This cookie exists on the JS returned by KMW's API calls. If one visits one of the links produced for an API query (example), then enters document.cookie into the developer mode console...

In this context, that cookie may be considered "same-site". Chrome raises no issues here. However, for KMW installations that aren't within the .keyman.com set of domains... that's where this becomes an issue, as the JS (with this cookie) is loaded and run via <script> tag on KMW's host page.

KMW itself doesn't need that cookie... so we can probably go with same-site only. My current question - where is that cookie coming from?

[jahorton]

Inspecting via the Headers tab...

Based on this:

api.keyman.com/web.config

Lines 61 to 82 in 5aeb41b

	<!-- Rewrites for /script folder: /cloud to /script/legacy/... -->
	<rule name="Language + keyboard map 4.0" stopProcessing="true">
	<match url="cloud/(4\.0\/)languages(\/([a-z0-9-]{2,}))(\/([a-z0-9_]+))" />
	<conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
	<action type="Rewrite" url="/script/legacy/legacy40.php?context=language&amp;languageid={R:3}&amp;keyboardid={R:5}" />
	</rule>
	<rule name="Language map 4.0" stopProcessing="true">
	<match url="cloud/(4\.0\/)languages(\/([a-z0-9-]{2,}))?" />
	<conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
	<action type="Rewrite" url="/script/legacy/legacy40.php?context=language&amp;languageid={R:3}" />
	</rule>
	<rule name="Keyboard + Language Map 4.0" stopProcessing="true">
	<match url="cloud/(4\.0\/)keyboards(\/([a-z0-9_]+))(\/([a-z0-9-]{2,}))" />
	<conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
	<action type="Rewrite" url="/script/legacy/legacy40.php?context=keyboard&amp;keyboardid={R:3}&amp;languageid={R:5}" />
	</rule>
	<rule name="Keyboard map 4.0" stopProcessing="true">
	<match url="cloud/(4\.0\/)keyboards(\/([a-z0-9_]+))?" />
	<conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
	<action type="Rewrite" url="/script/legacy/legacy40.php?context=keyboard&amp;keyboardid={R:3}" />
	</rule>

it would appear that this file would be the correct place to look. Except that a search op on that file doesn't bring up anything for either "header" or "_ga".

Then again, this is in the request header... from a raw query to that API endpoint. Just to be safe, I decided to load up the link in a completely fresh browser that had never followed it. (Opera, since I very recently downloaded it for something else.) No cookie was reported there... so maybe the original cause has already been fixed? That'd imply that the reason I still see the issues in Chrome is due to a 'never time out' setting when the cookie had been in active use.

Except that then visiting one of KMW's testing pages, within that browser, shows that there is one being set against .api.keyman.com, and it also produces those 4 requests.

Actually, upon re-examination, I can find that header information from the testing page (instead of through the direct query call), and there I see:

A couple of web searches later, and... https://stackoverflow.com/questions/50741024/does-arraffinity-cookie-always-set-on-azure-web-application

Looks like it's something being set by our hosting servers.

[jahorton]

Also worth notice: Chrome is now actively blocking these cookies for KMW's host page... and everything's working fine, without any targeted changes from us. That said, anyone making API calls against our servers will likely be seeing similar issue reports.

[mcdurdin]

_ga is Google Analytics

[mcdurdin]

I no longer see this occurring. It would be helpful to have a repro for these kinds of issues -- e.g. a link to the site where this was happening.