I am troubleshooting an interaction between a simplified version of ODK
Aggregate and ODK Survey, and my understanding of the ODK Tables sync is
that it is a series of REST calls. However I see JSESSION headers in the
communication. Are they necessary? What purpose do they fulfill?
My example request and the response coming back OK:
2017-04-12 15:36:05 GET http://192.168.86.113:9080/odktables/
← 200 application/json 31b 95ms
Example request headers:
Accept-Language: en
X-OpenDataKit-Version: 2.0
Accept-Encoding: gzip
User-Agent: Sync 210 (gzip)
···
Date: Wed, 12 Apr 2017 20:36:04 GMT+00:00
accept: application/json; q=1.0
accept: text/plain; charset=utf-8; q=0.4
Accept-Charset: UTF-8
Host: 192.168.86.113:9080
Connection: Keep-Alive
Example response headers:
Set-Cookie: JSESSIONID=23E3B86103C3821D5369BC2B47912D8D;path=/
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
ETag: md5:1a107507c9f875cb914e0670aae9ea1b
X-OpenDataKit-Version: 2.0
Content-Encoding: gzip
Vary: Accept-Encoding
Content-Type: application/json; q=1.0
Content-Length: 31
Date: Wed, 12 Apr 2017 20:36:05 GMT
Thank you for any insight,
Caden
To clarify, I know what they are normally used for-- sessions! I am just
wondering if they are really used by the odktables sync API since it is
otherwise a REST API.
···
On Wednesday, April 12, 2017 at 4:20:12 PM UTC-5, C. Howell wrote:
>
>
> I am troubleshooting an interaction between a simplified version of ODK
> Aggregate and ODK Survey, and my understanding of the ODK Tables sync is
> that it is a series of REST calls. However I see JSESSION headers in the
> communication. Are they necessary? What purpose do they fulfill?
>
>
>
> My example request and the response coming back OK:
>
> 2017-04-12 15:36:05 GET http://192.168.86.113:9080/odktables/
> ← 200 application/json 31b 95ms
>
>
> Example request headers:
>
> Accept-Language: en
>
> X-OpenDataKit-Version: 2.0
>
> Accept-Encoding: gzip
>
> User-Agent: Sync 210 (gzip)
>
> Date: Wed, 12 Apr 2017 20:36:04 GMT+00:00
>
> accept: application/json; q=1.0
>
> accept: text/plain; charset=utf-8; q=0.4
>
> Accept-Charset: UTF-8
>
> Host: 192.168.86.113:9080
>
> Connection: Keep-Alive
>
> Example response headers:
>
> Set-Cookie: JSESSIONID=23E3B86103C3821D5369BC2B47912D8D;path=/
>
> Access-Control-Allow-Credentials: true
>
> Access-Control-Allow-Origin: *
>
> ETag: md5:1a107507c9f875cb914e0670aae9ea1b
> X-OpenDataKit-Version: 2.0
>
> Content-Encoding: gzip
>
> Vary: Accept-Encoding
> Content-Type: application/json; q=1.0
>
> Content-Length: 31
>
> Date: Wed, 12 Apr 2017 20:36:05 GMT
>
> Thank you for any insight,
>
> Caden
>
>
ODK Aggregate uses Spring Security for securing all URLs on the site.
The configuration does not distinguish the interactive session pages from
the programmatic access pages (ODK Collect / ODK Briefcase apis and ODK
Sync REST apis).
The standard configuration negotiates digest auth or expects
proactively-supplied weak Oauth2 or out-of-band authentication credentials
then returns a session cookie which can be used to skip these lower-layer
authentication checks.
If you don’t use a cookie manager on your REST interactions (to retain and
echo back the session cookie), you will see a performance hit when using
digest auth because the initial request will be rejected and authentication
nonces negotiated.
For the other mechanisms, the proactively-supplied credentials avoid a
redirect/retry loop.
However, there is a slight penalty for Oauth2 because we make a call to
Google to verify credentials on each request with Oauth2 credentials and no
session cookie.
···
On Thu, Apr 13, 2017 at 9:54 AM, C. Howell wrote:
To clarify, I know what they are normally used for-- sessions! I am just
wondering if they are really used by the odktables sync API since it is
otherwise a REST API.
On Wednesday, April 12, 2017 at 4:20:12 PM UTC-5, C. Howell wrote:
I am troubleshooting an interaction between a simplified version of ODK
Aggregate and ODK Survey, and my understanding of the ODK Tables sync is
that it is a series of REST calls. However I see JSESSION headers in the
communication. Are they necessary? What purpose do they fulfill?
My example request and the response coming back OK:
2017-04-12 15:36:05 GET http://192.168.86.113:9080/odktables/
← 200 application/json 31b 95ms
Example request headers:
Accept-Language: en
X-OpenDataKit-Version: 2.0
Accept-Encoding: gzip
User-Agent: Sync 210 (gzip)
Date: Wed, 12 Apr 2017 20:36:04 GMT+00:00
accept: application/json; q=1.0
accept: text/plain; charset=utf-8; q=0.4
Accept-Charset: UTF-8
Host: 192.168.86.113:9080
Connection: Keep-Alive
Example response headers:
Set-Cookie: JSESSIONID=23E3B86103C3821D5369BC2B47912D8D;path=/
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
ETag: md5:1a107507c9f875cb914e0670aae9ea1b
X-OpenDataKit-Version: 2.0
Content-Encoding: gzip
Vary: Accept-Encoding
Content-Type: application/json; q=1.0
Content-Length: 31
Date: Wed, 12 Apr 2017 20:36:05 GMT
Thank you for any insight,
Caden
–
You received this message because you are subscribed to the Google Groups
“ODK Developers” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com