Hi,
I'm trying to add ODK authentication for Aggregate to enketo, and am having
trouble finding the urls to use when an server requires authentication.
For the form list, when using http://example.appspot.com/*
local_login.html?redirect=xformsList*, I can successfully authenticate but
the response is a HTML page (with a javascript redirect to the xformsList)
and not the xformsList itself. So I guess this url is probably not correct
(also because this url returns a 401 when authentication is not required).
I tried to find the location of the paths in the ODK Collect repo, but got
lost. Can anybody direct me please?
Thanks in advance,
Martijn
Note that authentication is using BasicAuth preferentially on the formList
and submission URLs.
It should accept OpenID credentials (but not negotiate to obtain them) and
also accept Oauth 1 credentials (but only when running on GAE, and it will
not negotiate to obtain them). Google Oauth 2 credentials for accessing
your gmail account e-mail address can also be used to gain access to the
server with the privileges of that gmail account.
The protocol is defined here:
https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaAPI
The request must specify the OpenRosa version header in order for the
OpenRosa behaviors to occur; if the header is omitted, you may get legacy
ODK Collect 1.6 and earlier form list and submission treatments.
Note that for browser viewing, I implemented /xformsList API, but that
should only be used for debugging. You should be sending the header on the
request and using the /formList URL to get exactly what Collect sees.
···
On Wed, Apr 24, 2013 at 5:43 PM, Martijn van de Rijdt < martijn@aidwebsolutions.com> wrote:
Hi,
I'm trying to add ODK authentication for Aggregate to enketo, and am
having trouble finding the urls to use when an server requires
authentication.
For the form list, when using http://example.appspot.com/*
local_login.html?redirect=xformsList*, I can successfully authenticate
but the response is a HTML page (with a javascript redirect to the
xformsList) and not the xformsList itself. So I guess this url is probably
not correct (also because this url returns a 401 when authentication is not
required).
I tried to find the location of the paths in the ODK Collect repo, but got
lost. Can anybody direct me please?
Thanks in advance,
Martijn
--
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/groups/opt_out.
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
Dear Mitch,
We are facing problem while trying to authenticate from phonegap(Cordova/Ionic) based mobile app to odk aggregate server. I have tried both basic and also digest to get the formlist from /formList of our server.
Our app gets the form list from https://opendatakit.appspot.com/formList perfectrly, but it is not being authenticate in our agreegate server where authentication is applied.
We have followed this ( https://bitbucket.org/javarosa/javarosa/wiki/AuthenticationAPI ) approach to connect but failed
Can you please suggest us any other approach.
Thanks in advance
Debashish
Thanks a lot Mitch. The header did the the trick to get the responses I was
looking for!
I didn't realize ODK Collect was using /formList (but see it in the
settings now). Enketo has been using /xformsList (which is actually the
same as /formList in formhub) to easily find media labels, the form's md5
hash and the md5 hashes of media resources. So ODK Collect is using the
knowledge of how Aggregate builds paths to those media urls and how it
makes the md5 hashes available?
···
On Wednesday, April 24, 2013 6:58:06 PM UTC-6, Mitch wrote:
>
> Note that authentication is using BasicAuth preferentially on the formList
> and submission URLs.
>
> It should accept OpenID credentials (but not negotiate to obtain them) and
> also accept Oauth 1 credentials (but only when running on GAE, and it will
> not negotiate to obtain them). Google Oauth 2 credentials for accessing
> your gmail account e-mail address can also be used to gain access to the
> server with the privileges of that gmail account.
>
> The protocol is defined here:
> https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaAPI
>
> The request must specify the OpenRosa version header in order for the
> OpenRosa behaviors to occur; if the header is omitted, you may get legacy
> ODK Collect 1.6 and earlier form list and submission treatments.
>
> Note that for browser viewing, I implemented /xformsList API, but that
> should only be used for debugging. You should be sending the header on the
> request and using the /formList URL to get exactly what Collect sees.
>
>
>
>
> On Wed, Apr 24, 2013 at 5:43 PM, Martijn van de Rijdt < mar...@aidwebsolutions.com > wrote:
>
>> Hi,
>>
>> I'm trying to add ODK authentication for Aggregate to enketo, and am
>> having trouble finding the urls to use when an server requires
>> authentication.
>>
>> For the form list, when using http://example.appspot.com/*
>> local_login.html?redirect=xformsList*, I can successfully authenticate
>> but the response is a HTML page (with a javascript redirect to the
>> xformsList) and not the xformsList itself. So I guess this url is probably
>> not correct (also because this url returns a 401 when authentication is not
>> required).
>>
>> I tried to find the location of the paths in the ODK Collect repo, but
>> got lost. Can anybody direct me please?
>>
>> Thanks in advance,
>> Martijn
>>
>>
>> --
>> 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/groups/opt_out.
>>
>>
>>
>
>
>
> --
> Mitch Sundt
> Software Engineer
> University of Washington
> mitche...@gmail.com
>
Collect uses no special knowledge. It just compares the md5 hashes, if they
differ, it fetches the file using the specified URL, otherwise it leaves
the already-fetched file unchanged.
The /xformsList URL was created purely for my ease of debugging. Since it
always emits a result in OpenRosa format, whether or not an OpenRosa
version header is supplied, you can open any browser and point it to
/xformsList to see what the OpenRosa response will be when you make a
well-formed OpenRosa request on /formList (specifying the version header).
The /xformsList URL does different authentication-failure handling vs.
/formList. It redirects to the interactive login-options screen, rather
than initiating the digest auth mechanism of the programmatic /formList and
/submission URLs. So if you are not yet authenticated, it will give you
the interactive authentication page vs. throwing you directly into the
digest auth negotiation.
Mitch
···
On Thu, Apr 25, 2013 at 7:46 AM, Martijn van de Rijdt < martijn@aidwebsolutions.com> wrote:
Thanks a lot Mitch. The header did the the trick to get the responses I
was looking for!
I didn't realize ODK Collect was using /formList (but see it in the
settings now). Enketo has been using /xformsList (which is actually the
same as /formList in formhub) to easily find media labels, the form's md5
hash and the md5 hashes of media resources. So ODK Collect is using the
knowledge of how Aggregate builds paths to those media urls and how it
makes the md5 hashes available?
On Wednesday, April 24, 2013 6:58:06 PM UTC-6, Mitch wrote:
Note that authentication is using BasicAuth preferentially on the
formList and submission URLs.
It should accept OpenID credentials (but not negotiate to obtain them)
and also accept Oauth 1 credentials (but only when running on GAE, and it
will not negotiate to obtain them). Google Oauth 2 credentials for
accessing your gmail account e-mail address can also be used to gain access
to the server with the privileges of that gmail account.
The protocol is defined here: https://bitbucket.org/**
javarosa/javarosa/wiki/**OpenRosaAPIhttps://bitbucket.org/javarosa/javarosa/wiki/OpenRosaAPI
The request must specify the OpenRosa version header in order for the
OpenRosa behaviors to occur; if the header is omitted, you may get legacy
ODK Collect 1.6 and earlier form list and submission treatments.
Note that for browser viewing, I implemented /xformsList API, but that
should only be used for debugging. You should be sending the header on the
request and using the /formList URL to get exactly what Collect sees.
On Wed, Apr 24, 2013 at 5:43 PM, Martijn van de Rijdt < mar...@aidwebsolutions.com> wrote:
Hi,
I'm trying to add ODK authentication for Aggregate to enketo, and am
having trouble finding the urls to use when an server requires
authentication.
For the form list, when using http://example.appspot.com/*loc
al_login.html?redirect=xformsList*, I can successfully authenticate but
the response is a HTML page (with a javascript redirect to the xformsList)
and not the xformsList itself. So I guess this url is probably not correct
(also because this url returns a 401 when authentication is not required).
I tried to find the location of the paths in the ODK Collect repo, but
got lost. Can anybody direct me please?
Thanks in advance,
Martijn
--
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/**groups/opt_outhttps://groups.google.com/groups/opt_out
.
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
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/groups/opt_out.
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
Thanks!
I see, it calculates the md5s locally, of course. Enketo has been lazily
relying on the info provided by the form server to see if a form or media
resource changed.
To obtain media label urls enketo goes from /(x)form(s)List to the url
mentioned in the manifestURL node if that exists (i.e. if there are media
labels). The advantage is that the form server can use any url structure it
wants for the xformsManifest and its listed resources and the client only
requires knowledge of the (x)forms(s)List url (and submission url).
So, I'm guessing ODK Collect goes straight to /xformsManifest to obtain
these media resources?
(https://jrosaforms.appspot.com/xformsManifest?formId=NewWidgets)
Cheers,
Martijn
···
On Thu, Apr 25, 2013 at 11:01 AM, Mitch Sundt wrote:
Collect uses no special knowledge. It just compares the md5 hashes, if
they differ, it fetches the file using the specified URL, otherwise it
leaves the already-fetched file unchanged.
The /xformsList URL was created purely for my ease of debugging. Since it
always emits a result in OpenRosa format, whether or not an OpenRosa
version header is supplied, you can open any browser and point it to
/xformsList to see what the OpenRosa response will be when you make a
well-formed OpenRosa request on /formList (specifying the version header).
The /xformsList URL does different authentication-failure handling vs.
/formList. It redirects to the interactive login-options screen, rather
than initiating the digest auth mechanism of the programmatic /formList and
/submission URLs. So if you are not yet authenticated, it will give you
the interactive authentication page vs. throwing you directly into the
digest auth negotiation.
Mitch
On Thu, Apr 25, 2013 at 7:46 AM, Martijn van de Rijdt < martijn@aidwebsolutions.com> wrote:
Thanks a lot Mitch. The header did the the trick to get the responses I
was looking for!
I didn't realize ODK Collect was using /formList (but see it in the
settings now). Enketo has been using /xformsList (which is actually the
same as /formList in formhub) to easily find media labels, the form's md5
hash and the md5 hashes of media resources. So ODK Collect is using the
knowledge of how Aggregate builds paths to those media urls and how it
makes the md5 hashes available?
On Wednesday, April 24, 2013 6:58:06 PM UTC-6, Mitch wrote:
Note that authentication is using BasicAuth preferentially on the
formList and submission URLs.
It should accept OpenID credentials (but not negotiate to obtain them)
and also accept Oauth 1 credentials (but only when running on GAE, and it
will not negotiate to obtain them). Google Oauth 2 credentials for
accessing your gmail account e-mail address can also be used to gain access
to the server with the privileges of that gmail account.
The protocol is defined here: https://bitbucket.org/**
javarosa/javarosa/wiki/**OpenRosaAPIhttps://bitbucket.org/javarosa/javarosa/wiki/OpenRosaAPI
The request must specify the OpenRosa version header in order for the
OpenRosa behaviors to occur; if the header is omitted, you may get legacy
ODK Collect 1.6 and earlier form list and submission treatments.
Note that for browser viewing, I implemented /xformsList API, but that
should only be used for debugging. You should be sending the header on the
request and using the /formList URL to get exactly what Collect sees.
On Wed, Apr 24, 2013 at 5:43 PM, Martijn van de Rijdt < mar...@aidwebsolutions.com> wrote:
Hi,
I'm trying to add ODK authentication for Aggregate to enketo, and am
having trouble finding the urls to use when an server requires
authentication.
For the form list, when using http://example.appspot.com/*loc
al_login.html?redirect=xformsList*, I can successfully authenticate
but the response is a HTML page (with a javascript redirect to the
xformsList) and not the xformsList itself. So I guess this url is probably
not correct (also because this url returns a 401 when authentication is not
required).
I tried to find the location of the paths in the ODK Collect repo, but
got lost. Can anybody direct me please?
Thanks in advance,
Martijn
--
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/**groups/opt_outhttps://groups.google.com/groups/opt_out
.
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
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/groups/opt_out.
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/OrIpNbrWvtY/unsubscribe?hl=en
.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Enketo http://enketo.org | LinkedIn
http://www.linkedin.com/in/martijnvanderijdt/ |
GitHubhttps://github.com/MartijnR
Correct, md5s are directly computed off the files. This is because users
can, at any time, connect their devices to a laptop and copy files into
those directories, so we need to look at 'ground truth' of the SDCard file
system and cannot rely on md5 hash values stored in, e.g., a database, for
change detection.
No, if the manifest URL is supplied, ODK Collect just uses it to get the
list of media files, etc. ODK Collect does not attempt to construct the
manifest URL with any a priori knowledge of what it should look like.
Furthermore, if you configure ODK Collect to use a 'Other' Platform, then
you can specify URL paths other than /formList and /submission (even when
'Other' is selected, ODK Collect still assumes that all communications are
using the OpenRosa API).
In this way, there is no fixed, a priori, assumption about the server's URL
paths. We only assume it implements the OpenRosa API.
If the server doesn't, then ODK Collect falls back to interpreting the
result as if it were an ODK Aggregate 0.9.x interaction (as it turns out,
this only affects /formList result processing, as 0.9.x did not support
downloading forms with multimedia prompts).
···
On Thu, Apr 25, 2013 at 10:16 AM, Martijn van de Rijdt wrote:
Thanks!
I see, it calculates the md5s locally, of course. Enketo has been lazily
relying on the info provided by the form server to see if a form or media
resource changed.
To obtain media label urls enketo goes from /(x)form(s)List to the url
mentioned in the manifestURL node if that exists (i.e. if there are media
labels). The advantage is that the form server can use any url structure it
wants for the xformsManifest and its listed resources and the client only
requires knowledge of the (x)forms(s)List url (and submission url).
So, I'm guessing ODK Collect goes straight to /xformsManifest to obtain
these media resources?
(https://jrosaforms.appspot.com/xformsManifest?formId=NewWidgets)
Cheers,
Martijn
On Thu, Apr 25, 2013 at 11:01 AM, Mitch Sundt mitchellsundt@gmail.comwrote:
Collect uses no special knowledge. It just compares the md5 hashes, if
they differ, it fetches the file using the specified URL, otherwise it
leaves the already-fetched file unchanged.
The /xformsList URL was created purely for my ease of debugging. Since it
always emits a result in OpenRosa format, whether or not an OpenRosa
version header is supplied, you can open any browser and point it to
/xformsList to see what the OpenRosa response will be when you make a
well-formed OpenRosa request on /formList (specifying the version header).
The /xformsList URL does different authentication-failure handling vs.
/formList. It redirects to the interactive login-options screen, rather
than initiating the digest auth mechanism of the programmatic /formList and
/submission URLs. So if you are not yet authenticated, it will give you
the interactive authentication page vs. throwing you directly into the
digest auth negotiation.
Mitch
On Thu, Apr 25, 2013 at 7:46 AM, Martijn van de Rijdt < martijn@aidwebsolutions.com> wrote:
Thanks a lot Mitch. The header did the the trick to get the responses I
was looking for!
I didn't realize ODK Collect was using /formList (but see it in the
settings now). Enketo has been using /xformsList (which is actually the
same as /formList in formhub) to easily find media labels, the form's md5
hash and the md5 hashes of media resources. So ODK Collect is using the
knowledge of how Aggregate builds paths to those media urls and how it
makes the md5 hashes available?
On Wednesday, April 24, 2013 6:58:06 PM UTC-6, Mitch wrote:
Note that authentication is using BasicAuth preferentially on the
formList and submission URLs.
It should accept OpenID credentials (but not negotiate to obtain them)
and also accept Oauth 1 credentials (but only when running on GAE, and it
will not negotiate to obtain them). Google Oauth 2 credentials for
accessing your gmail account e-mail address can also be used to gain access
to the server with the privileges of that gmail account.
The protocol is defined here: https://bitbucket.org/**
javarosa/javarosa/wiki/**OpenRosaAPIhttps://bitbucket.org/javarosa/javarosa/wiki/OpenRosaAPI
The request must specify the OpenRosa version header in order for the
OpenRosa behaviors to occur; if the header is omitted, you may get legacy
ODK Collect 1.6 and earlier form list and submission treatments.
Note that for browser viewing, I implemented /xformsList API, but that
should only be used for debugging. You should be sending the header on the
request and using the /formList URL to get exactly what Collect sees.
On Wed, Apr 24, 2013 at 5:43 PM, Martijn van de Rijdt < mar...@aidwebsolutions.com> wrote:
Hi,
I'm trying to add ODK authentication for Aggregate to enketo, and am
having trouble finding the urls to use when an server requires
authentication.
For the form list, when using http://example.appspot.com/*loc
al_login.html?redirect=xformsList*, I can successfully authenticate
but the response is a HTML page (with a javascript redirect to the
xformsList) and not the xformsList itself. So I guess this url is probably
not correct (also because this url returns a 401 when authentication is not
required).
I tried to find the location of the paths in the ODK Collect repo, but
got lost. Can anybody direct me please?
Thanks in advance,
Martijn
--
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/**groups/opt_outhttps://groups.google.com/groups/opt_out
.
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
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/groups/opt_out.
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/OrIpNbrWvtY/unsubscribe?hl=en
.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Enketo http://enketo.org | LinkedIn
http://www.linkedin.com/in/martijnvanderijdt/ | GitHubhttps://github.com/MartijnR
--
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/groups/opt_out.
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
Thanks again.
The only part that confuses me is how ODK Collect will know about the
presence of a manifestUrl since /formList doesn't seem to show that.
http://opendatakit.appspot.com/formList (or is this a v0.9.x instance?)
···
On Thu, Apr 25, 2013 at 11:35 AM, Mitch Sundt wrote:
Correct, md5s are directly computed off the files. This is because users
can, at any time, connect their devices to a laptop and copy files into
those directories, so we need to look at 'ground truth' of the SDCard file
system and cannot rely on md5 hash values stored in, e.g., a database, for
change detection.
No, if the manifest URL is supplied, ODK Collect just uses it to get the
list of media files, etc. ODK Collect does not attempt to construct the
manifest URL with any a priori knowledge of what it should look like.
Furthermore, if you configure ODK Collect to use a 'Other' Platform, then
you can specify URL paths other than /formList and /submission (even when
'Other' is selected, ODK Collect still assumes that all communications are
using the OpenRosa API).
In this way, there is no fixed, a priori, assumption about the server's
URL paths. We only assume it implements the OpenRosa API.
If the server doesn't, then ODK Collect falls back to interpreting the
result as if it were an ODK Aggregate 0.9.x interaction (as it turns out,
this only affects /formList result processing, as 0.9.x did not support
downloading forms with multimedia prompts).
On Thu, Apr 25, 2013 at 10:16 AM, Martijn van de Rijdt m@enketo.orgwrote:
Thanks!
I see, it calculates the md5s locally, of course. Enketo has been lazily
relying on the info provided by the form server to see if a form or media
resource changed.
To obtain media label urls enketo goes from /(x)form(s)List to the url
mentioned in the manifestURL node if that exists (i.e. if there are media
labels). The advantage is that the form server can use any url structure it
wants for the xformsManifest and its listed resources and the client only
requires knowledge of the (x)forms(s)List url (and submission url).
So, I'm guessing ODK Collect goes straight to /xformsManifest to obtain
these media resources?
(https://jrosaforms.appspot.com/xformsManifest?formId=NewWidgets)
Cheers,
Martijn
On Thu, Apr 25, 2013 at 11:01 AM, Mitch Sundt mitchellsundt@gmail.comwrote:
Collect uses no special knowledge. It just compares the md5 hashes, if
they differ, it fetches the file using the specified URL, otherwise it
leaves the already-fetched file unchanged.
The /xformsList URL was created purely for my ease of debugging. Since
it always emits a result in OpenRosa format, whether or not an OpenRosa
version header is supplied, you can open any browser and point it to
/xformsList to see what the OpenRosa response will be when you make a
well-formed OpenRosa request on /formList (specifying the version header).
The /xformsList URL does different authentication-failure handling vs.
/formList. It redirects to the interactive login-options screen, rather
than initiating the digest auth mechanism of the programmatic /formList and
/submission URLs. So if you are not yet authenticated, it will give you
the interactive authentication page vs. throwing you directly into the
digest auth negotiation.
Mitch
On Thu, Apr 25, 2013 at 7:46 AM, Martijn van de Rijdt < martijn@aidwebsolutions.com> wrote:
Thanks a lot Mitch. The header did the the trick to get the responses I
was looking for!
I didn't realize ODK Collect was using /formList (but see it in the
settings now). Enketo has been using /xformsList (which is actually the
same as /formList in formhub) to easily find media labels, the form's md5
hash and the md5 hashes of media resources. So ODK Collect is using the
knowledge of how Aggregate builds paths to those media urls and how it
makes the md5 hashes available?
On Wednesday, April 24, 2013 6:58:06 PM UTC-6, Mitch wrote:
Note that authentication is using BasicAuth preferentially on the
formList and submission URLs.
It should accept OpenID credentials (but not negotiate to obtain them)
and also accept Oauth 1 credentials (but only when running on GAE, and it
will not negotiate to obtain them). Google Oauth 2 credentials for
accessing your gmail account e-mail address can also be used to gain access
to the server with the privileges of that gmail account.
The protocol is defined here: https://bitbucket.org/**
javarosa/javarosa/wiki/**OpenRosaAPIhttps://bitbucket.org/javarosa/javarosa/wiki/OpenRosaAPI
The request must specify the OpenRosa version header in order for the
OpenRosa behaviors to occur; if the header is omitted, you may get legacy
ODK Collect 1.6 and earlier form list and submission treatments.
Note that for browser viewing, I implemented /xformsList API, but that
should only be used for debugging. You should be sending the header on the
request and using the /formList URL to get exactly what Collect sees.
On Wed, Apr 24, 2013 at 5:43 PM, Martijn van de Rijdt < mar...@aidwebsolutions.com> wrote:
Hi,
I'm trying to add ODK authentication for Aggregate to enketo, and am
having trouble finding the urls to use when an server requires
authentication.
For the form list, when using http://example.appspot.com/*loc
al_login.html?redirect=xformsList*, I can successfully authenticate
but the response is a HTML page (with a javascript redirect to the
xformsList) and not the xformsList itself. So I guess this url is probably
not correct (also because this url returns a 401 when authentication is not
required).
I tried to find the location of the paths in the ODK Collect repo,
but got lost. Can anybody direct me please?
Thanks in advance,
Martijn
--
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/**groups/opt_outhttps://groups.google.com/groups/opt_out
.
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
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/groups/opt_out.
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/OrIpNbrWvtY/unsubscribe?hl=en
.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Enketo http://enketo.org | LinkedIn
http://www.linkedin.com/in/martijnvanderijdt/ | GitHubhttps://github.com/MartijnR
--
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/groups/opt_out.
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/OrIpNbrWvtY/unsubscribe?hl=en
.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Enketo http://enketo.org | LinkedIn
http://www.linkedin.com/in/martijnvanderijdt/ |
GitHubhttps://github.com/MartijnR
Again, if you open /formList in a browser, it will lack the OpenRosa
version header (
https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaRequest ).
In that case, ODK Aggregate assumes it is communicating with an ODK Collect
built prior to version 1.1.6 (prior to the OpenRosa standard being agreed
upon).
And ODK Aggregate returns the old-style, pre-1.1.6, non-standard, form
discovery document.
If you instead supply the OpenRosa version header on your /formList
request, it will return the OpenRosa response format. This is exactly what
you see when you visit /xformsList in a browser; the difference being that
/formList chooses what output it returns by looking at the header, while
/xformsList always returns the OpenRosa response format, whether or not the
requester has sent a proper OpenRosa request.
ODK Collect, starting with 1.1.6, always supplies the OpenRosa version
header, so it will always see the OpenRosa response, and that will always
contain the manifest URL if there are multimedia prompts in the form.
Mitch
···
On Thu, Apr 25, 2013 at 11:01 AM, Martijn van de Rijdt wrote:
Thanks again.
The only part that confuses me is how ODK Collect will know about the
presence of a manifestUrl since /formList doesn't seem to show that.
http://opendatakit.appspot.com/formList (or is this a v0.9.x instance?)
On Thu, Apr 25, 2013 at 11:35 AM, Mitch Sundt mitchellsundt@gmail.comwrote:
Correct, md5s are directly computed off the files. This is because users
can, at any time, connect their devices to a laptop and copy files into
those directories, so we need to look at 'ground truth' of the SDCard file
system and cannot rely on md5 hash values stored in, e.g., a database, for
change detection.
No, if the manifest URL is supplied, ODK Collect just uses it to get the
list of media files, etc. ODK Collect does not attempt to construct the
manifest URL with any a priori knowledge of what it should look like.
Furthermore, if you configure ODK Collect to use a 'Other' Platform, then
you can specify URL paths other than /formList and /submission (even when
'Other' is selected, ODK Collect still assumes that all communications are
using the OpenRosa API).
In this way, there is no fixed, a priori, assumption about the server's
URL paths. We only assume it implements the OpenRosa API.
If the server doesn't, then ODK Collect falls back to interpreting the
result as if it were an ODK Aggregate 0.9.x interaction (as it turns out,
this only affects /formList result processing, as 0.9.x did not support
downloading forms with multimedia prompts).
On Thu, Apr 25, 2013 at 10:16 AM, Martijn van de Rijdt m@enketo.orgwrote:
Thanks!
I see, it calculates the md5s locally, of course. Enketo has been lazily
relying on the info provided by the form server to see if a form or media
resource changed.
To obtain media label urls enketo goes from /(x)form(s)List to the url
mentioned in the manifestURL node if that exists (i.e. if there are media
labels). The advantage is that the form server can use any url structure it
wants for the xformsManifest and its listed resources and the client only
requires knowledge of the (x)forms(s)List url (and submission url).
So, I'm guessing ODK Collect goes straight to /xformsManifest to obtain
these media resources?
(https://jrosaforms.appspot.com/xformsManifest?formId=NewWidgets)
Cheers,
Martijn
On Thu, Apr 25, 2013 at 11:01 AM, Mitch Sundt mitchellsundt@gmail.comwrote:
Collect uses no special knowledge. It just compares the md5 hashes, if
they differ, it fetches the file using the specified URL, otherwise it
leaves the already-fetched file unchanged.
The /xformsList URL was created purely for my ease of debugging. Since
it always emits a result in OpenRosa format, whether or not an OpenRosa
version header is supplied, you can open any browser and point it to
/xformsList to see what the OpenRosa response will be when you make a
well-formed OpenRosa request on /formList (specifying the version header).
The /xformsList URL does different authentication-failure handling vs.
/formList. It redirects to the interactive login-options screen, rather
than initiating the digest auth mechanism of the programmatic /formList and
/submission URLs. So if you are not yet authenticated, it will give you
the interactive authentication page vs. throwing you directly into the
digest auth negotiation.
Mitch
On Thu, Apr 25, 2013 at 7:46 AM, Martijn van de Rijdt < martijn@aidwebsolutions.com> wrote:
Thanks a lot Mitch. The header did the the trick to get the responses
I was looking for!
I didn't realize ODK Collect was using /formList (but see it in the
settings now). Enketo has been using /xformsList (which is actually the
same as /formList in formhub) to easily find media labels, the form's md5
hash and the md5 hashes of media resources. So ODK Collect is using the
knowledge of how Aggregate builds paths to those media urls and how it
makes the md5 hashes available?
On Wednesday, April 24, 2013 6:58:06 PM UTC-6, Mitch wrote:
Note that authentication is using BasicAuth preferentially on the
formList and submission URLs.
It should accept OpenID credentials (but not negotiate to obtain
them) and also accept Oauth 1 credentials (but only when running on GAE,
and it will not negotiate to obtain them). Google Oauth 2 credentials for
accessing your gmail account e-mail address can also be used to gain access
to the server with the privileges of that gmail account.
The protocol is defined here: https://bitbucket.org/**
javarosa/javarosa/wiki/**OpenRosaAPIhttps://bitbucket.org/javarosa/javarosa/wiki/OpenRosaAPI
The request must specify the OpenRosa version header in order for the
OpenRosa behaviors to occur; if the header is omitted, you may get legacy
ODK Collect 1.6 and earlier form list and submission treatments.
Note that for browser viewing, I implemented /xformsList API, but
that should only be used for debugging. You should be sending the header on
the request and using the /formList URL to get exactly what Collect sees.
On Wed, Apr 24, 2013 at 5:43 PM, Martijn van de Rijdt < mar...@aidwebsolutions.com> wrote:
Hi,
I'm trying to add ODK authentication for Aggregate to enketo, and am
having trouble finding the urls to use when an server requires
authentication.
For the form list, when using http://example.appspot.com/*loc
al_login.html?redirect=xformsList*, I can successfully authenticate
but the response is a HTML page (with a javascript redirect to the
xformsList) and not the xformsList itself. So I guess this url is probably
not correct (also because this url returns a 401 when authentication is not
required).
I tried to find the location of the paths in the ODK Collect repo,
but got lost. Can anybody direct me please?
Thanks in advance,
Martijn
--
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/**groups/opt_outhttps://groups.google.com/groups/opt_out
.
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
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/groups/opt_out.
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/OrIpNbrWvtY/unsubscribe?hl=en
.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Enketo http://enketo.org | LinkedIn
http://www.linkedin.com/in/martijnvanderijdt/ | GitHubhttps://github.com/MartijnR
--
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/groups/opt_out.
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/OrIpNbrWvtY/unsubscribe?hl=en
.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Enketo http://enketo.org | LinkedIn
http://www.linkedin.com/in/martijnvanderijdt/ | GitHubhttps://github.com/MartijnR
--
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/groups/opt_out.
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
To make this clear to everyone on the list, when the protocols changed the
ODK team put in special logic in Aggregate to detect which protocol was
being used so that it was a smooth transition allowing people using and old
and new protocols to not have to run two separate versions of Aggregate.
/formList is the correct URL on Aggregate and Aggregate will automatically
adjust to the protocol version the contacting device is speaking.
/xformList is used for debugging only and may disappear at anytime.
Waylon
···
On Thu, Apr 25, 2013 at 11:28 AM, Mitch Sundt wrote:
Again, if you open /formList in a browser, it will lack the OpenRosa
version header (
https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaRequest ).
In that case, ODK Aggregate assumes it is communicating with an ODK
Collect built prior to version 1.1.6 (prior to the OpenRosa standard being
agreed upon).
And ODK Aggregate returns the old-style, pre-1.1.6, non-standard, form
discovery document.
If you instead supply the OpenRosa version header on your /formList
request, it will return the OpenRosa response format. This is exactly what
you see when you visit /xformsList in a browser; the difference being that
/formList chooses what output it returns by looking at the header, while
/xformsList always returns the OpenRosa response format, whether or not the
requester has sent a proper OpenRosa request.
ODK Collect, starting with 1.1.6, always supplies the OpenRosa version
header, so it will always see the OpenRosa response, and that will always
contain the manifest URL if there are multimedia prompts in the form.
Mitch
On Thu, Apr 25, 2013 at 11:01 AM, Martijn van de Rijdt m@enketo.orgwrote:
Thanks again.
The only part that confuses me is how ODK Collect will know about the
presence of a manifestUrl since /formList doesn't seem to show that.
http://opendatakit.appspot.com/formList (or is this a v0.9.x instance?)
On Thu, Apr 25, 2013 at 11:35 AM, Mitch Sundt mitchellsundt@gmail.comwrote:
Correct, md5s are directly computed off the files. This is because users
can, at any time, connect their devices to a laptop and copy files into
those directories, so we need to look at 'ground truth' of the SDCard file
system and cannot rely on md5 hash values stored in, e.g., a database, for
change detection.
No, if the manifest URL is supplied, ODK Collect just uses it to get the
list of media files, etc. ODK Collect does not attempt to construct the
manifest URL with any a priori knowledge of what it should look like.
Furthermore, if you configure ODK Collect to use a 'Other' Platform, then
you can specify URL paths other than /formList and /submission (even when
'Other' is selected, ODK Collect still assumes that all communications are
using the OpenRosa API).
In this way, there is no fixed, a priori, assumption about the server's
URL paths. We only assume it implements the OpenRosa API.
If the server doesn't, then ODK Collect falls back to interpreting the
result as if it were an ODK Aggregate 0.9.x interaction (as it turns out,
this only affects /formList result processing, as 0.9.x did not support
downloading forms with multimedia prompts).
On Thu, Apr 25, 2013 at 10:16 AM, Martijn van de Rijdt m@enketo.orgwrote:
Thanks!
I see, it calculates the md5s locally, of course. Enketo has been
lazily relying on the info provided by the form server to see if a form or
media resource changed.
To obtain media label urls enketo goes from /(x)form(s)List to the url
mentioned in the manifestURL node if that exists (i.e. if there are media
labels). The advantage is that the form server can use any url structure it
wants for the xformsManifest and its listed resources and the client only
requires knowledge of the (x)forms(s)List url (and submission url).
So, I'm guessing ODK Collect goes straight to /xformsManifest to obtain
these media resources?
(https://jrosaforms.appspot.com/xformsManifest?formId=NewWidgets)
Cheers,
Martijn
On Thu, Apr 25, 2013 at 11:01 AM, Mitch Sundt mitchellsundt@gmail.comwrote:
Collect uses no special knowledge. It just compares the md5 hashes, if
they differ, it fetches the file using the specified URL, otherwise it
leaves the already-fetched file unchanged.
The /xformsList URL was created purely for my ease of debugging. Since
it always emits a result in OpenRosa format, whether or not an OpenRosa
version header is supplied, you can open any browser and point it to
/xformsList to see what the OpenRosa response will be when you make a
well-formed OpenRosa request on /formList (specifying the version header).
The /xformsList URL does different authentication-failure handling vs.
/formList. It redirects to the interactive login-options screen, rather
than initiating the digest auth mechanism of the programmatic /formList and
/submission URLs. So if you are not yet authenticated, it will give you
the interactive authentication page vs. throwing you directly into the
digest auth negotiation.
Mitch
On Thu, Apr 25, 2013 at 7:46 AM, Martijn van de Rijdt < martijn@aidwebsolutions.com> wrote:
Thanks a lot Mitch. The header did the the trick to get the responses
I was looking for!
I didn't realize ODK Collect was using /formList (but see it in the
settings now). Enketo has been using /xformsList (which is actually the
same as /formList in formhub) to easily find media labels, the form's md5
hash and the md5 hashes of media resources. So ODK Collect is using the
knowledge of how Aggregate builds paths to those media urls and how it
makes the md5 hashes available?
On Wednesday, April 24, 2013 6:58:06 PM UTC-6, Mitch wrote:
Note that authentication is using BasicAuth preferentially on the
formList and submission URLs.
It should accept OpenID credentials (but not negotiate to obtain
them) and also accept Oauth 1 credentials (but only when running on GAE,
and it will not negotiate to obtain them). Google Oauth 2 credentials for
accessing your gmail account e-mail address can also be used to gain access
to the server with the privileges of that gmail account.
The protocol is defined here: https://bitbucket.org/**
javarosa/javarosa/wiki/**OpenRosaAPIhttps://bitbucket.org/javarosa/javarosa/wiki/OpenRosaAPI
The request must specify the OpenRosa version header in order for
the OpenRosa behaviors to occur; if the header is omitted, you may get
legacy ODK Collect 1.6 and earlier form list and submission treatments.
Note that for browser viewing, I implemented /xformsList API, but
that should only be used for debugging. You should be sending the header on
the request and using the /formList URL to get exactly what Collect sees.
On Wed, Apr 24, 2013 at 5:43 PM, Martijn van de Rijdt < mar...@aidwebsolutions.com> wrote:
Hi,
I'm trying to add ODK authentication for Aggregate to enketo, and
am having trouble finding the urls to use when an server requires
authentication.
For the form list, when using http://example.appspot.com/*loc
al_login.html?redirect=xformsList*, I can successfully
authenticate but the response is a HTML page (with a javascript redirect to
the xformsList) and not the xformsList itself. So I guess this url is
probably not correct (also because this url returns a 401 when
authentication is not required).
I tried to find the location of the paths in the ODK Collect repo,
but got lost. Can anybody direct me please?
Thanks in advance,
Martijn
--
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/**groups/opt_outhttps://groups.google.com/groups/opt_out
.
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
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/groups/opt_out.
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/OrIpNbrWvtY/unsubscribe?hl=en
.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Enketo http://enketo.org | LinkedIn
http://www.linkedin.com/in/martijnvanderijdt/ | GitHubhttps://github.com/MartijnR
--
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/groups/opt_out.
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/OrIpNbrWvtY/unsubscribe?hl=en
.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Enketo http://enketo.org | LinkedIn
http://www.linkedin.com/in/martijnvanderijdt/ | GitHubhttps://github.com/MartijnR
--
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/groups/opt_out.
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
--
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/groups/opt_out.
Ah yes, of course. Again the header. Thanks!
···
On Thu, Apr 25, 2013 at 12:55 PM, W. Brunette wrote:
To make this clear to everyone on the list, when the protocols changed the
ODK team put in special logic in Aggregate to detect which protocol was
being used so that it was a smooth transition allowing people using and old
and new protocols to not have to run two separate versions of Aggregate.
/formList is the correct URL on Aggregate and Aggregate will automatically
adjust to the protocol version the contacting device is speaking.
/xformList is used for debugging only and may disappear at anytime.
Waylon
On Thu, Apr 25, 2013 at 11:28 AM, Mitch Sundt mitchellsundt@gmail.comwrote:
Again, if you open /formList in a browser, it will lack the OpenRosa
version header (
https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaRequest ).
In that case, ODK Aggregate assumes it is communicating with an ODK
Collect built prior to version 1.1.6 (prior to the OpenRosa standard being
agreed upon).
And ODK Aggregate returns the old-style, pre-1.1.6, non-standard, form
discovery document.
If you instead supply the OpenRosa version header on your /formList
request, it will return the OpenRosa response format. This is exactly what
you see when you visit /xformsList in a browser; the difference being that
/formList chooses what output it returns by looking at the header, while
/xformsList always returns the OpenRosa response format, whether or not the
requester has sent a proper OpenRosa request.
ODK Collect, starting with 1.1.6, always supplies the OpenRosa version
header, so it will always see the OpenRosa response, and that will always
contain the manifest URL if there are multimedia prompts in the form.
Mitch
On Thu, Apr 25, 2013 at 11:01 AM, Martijn van de Rijdt m@enketo.orgwrote:
Thanks again.
The only part that confuses me is how ODK Collect will know about the
presence of a manifestUrl since /formList doesn't seem to show that.
http://opendatakit.appspot.com/formList (or is this a v0.9.x instance?)
On Thu, Apr 25, 2013 at 11:35 AM, Mitch Sundt mitchellsundt@gmail.comwrote:
Correct, md5s are directly computed off the files. This is because
users can, at any time, connect their devices to a laptop and copy files
into those directories, so we need to look at 'ground truth' of the SDCard
file system and cannot rely on md5 hash values stored in, e.g., a database,
for change detection.
No, if the manifest URL is supplied, ODK Collect just uses it to get
the list of media files, etc. ODK Collect does not attempt to construct the
manifest URL with any a priori knowledge of what it should look like.
Furthermore, if you configure ODK Collect to use a 'Other' Platform, then
you can specify URL paths other than /formList and /submission (even when
'Other' is selected, ODK Collect still assumes that all communications are
using the OpenRosa API).
In this way, there is no fixed, a priori, assumption about the server's
URL paths. We only assume it implements the OpenRosa API.
If the server doesn't, then ODK Collect falls back to interpreting the
result as if it were an ODK Aggregate 0.9.x interaction (as it turns out,
this only affects /formList result processing, as 0.9.x did not support
downloading forms with multimedia prompts).
On Thu, Apr 25, 2013 at 10:16 AM, Martijn van de Rijdt m@enketo.orgwrote:
Thanks!
I see, it calculates the md5s locally, of course. Enketo has been
lazily relying on the info provided by the form server to see if a form or
media resource changed.
To obtain media label urls enketo goes from /(x)form(s)List to the url
mentioned in the manifestURL node if that exists (i.e. if there are media
labels). The advantage is that the form server can use any url structure it
wants for the xformsManifest and its listed resources and the client only
requires knowledge of the (x)forms(s)List url (and submission url).
So, I'm guessing ODK Collect goes straight to /xformsManifest to
obtain these media resources?
(https://jrosaforms.appspot.com/xformsManifest?formId=NewWidgets)
Cheers,
Martijn
On Thu, Apr 25, 2013 at 11:01 AM, Mitch Sundt <mitchellsundt@gmail.com wrote:
Collect uses no special knowledge. It just compares the md5 hashes,
if they differ, it fetches the file using the specified URL, otherwise it
leaves the already-fetched file unchanged.
The /xformsList URL was created purely for my ease of debugging.
Since it always emits a result in OpenRosa format, whether or not an
OpenRosa version header is supplied, you can open any browser and point it
to /xformsList to see what the OpenRosa response will be when you make a
well-formed OpenRosa request on /formList (specifying the version header).
The /xformsList URL does different authentication-failure handling
vs. /formList. It redirects to the interactive login-options screen,
rather than initiating the digest auth mechanism of the programmatic
/formList and /submission URLs. So if you are not yet authenticated, it
will give you the interactive authentication page vs. throwing you directly
into the digest auth negotiation.
Mitch
On Thu, Apr 25, 2013 at 7:46 AM, Martijn van de Rijdt < martijn@aidwebsolutions.com> wrote:
Thanks a lot Mitch. The header did the the trick to get the
responses I was looking for!
I didn't realize ODK Collect was using /formList (but see it in the
settings now). Enketo has been using /xformsList (which is actually the
same as /formList in formhub) to easily find media labels, the form's md5
hash and the md5 hashes of media resources. So ODK Collect is using the
knowledge of how Aggregate builds paths to those media urls and how it
makes the md5 hashes available?
On Wednesday, April 24, 2013 6:58:06 PM UTC-6, Mitch wrote:
Note that authentication is using BasicAuth preferentially on the
formList and submission URLs.
It should accept OpenID credentials (but not negotiate to obtain
them) and also accept Oauth 1 credentials (but only when running on GAE,
and it will not negotiate to obtain them). Google Oauth 2 credentials for
accessing your gmail account e-mail address can also be used to gain access
to the server with the privileges of that gmail account.
The protocol is defined here: https://bitbucket.org/**
javarosa/javarosa/wiki/**OpenRosaAPIhttps://bitbucket.org/javarosa/javarosa/wiki/OpenRosaAPI
The request must specify the OpenRosa version header in order for
the OpenRosa behaviors to occur; if the header is omitted, you may get
legacy ODK Collect 1.6 and earlier form list and submission treatments.
Note that for browser viewing, I implemented /xformsList API, but
that should only be used for debugging. You should be sending the header on
the request and using the /formList URL to get exactly what Collect sees.
On Wed, Apr 24, 2013 at 5:43 PM, Martijn van de Rijdt < mar...@aidwebsolutions.com> wrote:
Hi,
I'm trying to add ODK authentication for Aggregate to enketo, and
am having trouble finding the urls to use when an server requires
authentication.
For the form list, when using http://example.appspot.com/*loc
al_login.html?redirect=xformsList*, I can successfully
authenticate but the response is a HTML page (with a javascript redirect to
the xformsList) and not the xformsList itself. So I guess this url is
probably not correct (also because this url returns a 401 when
authentication is not required).
I tried to find the location of the paths in the ODK Collect repo,
but got lost. Can anybody direct me please?
Thanks in advance,
Martijn
--
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/**groups/opt_outhttps://groups.google.com/groups/opt_out
.
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
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/groups/opt_out.
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
--
You received this message because you are subscribed to a topic in
the Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/OrIpNbrWvtY/unsubscribe?hl=en
.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Enketo http://enketo.org | LinkedIn
http://www.linkedin.com/in/martijnvanderijdt/ | GitHubhttps://github.com/MartijnR
--
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/groups/opt_out.
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/OrIpNbrWvtY/unsubscribe?hl=en
.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Enketo http://enketo.org | LinkedIn
http://www.linkedin.com/in/martijnvanderijdt/ | GitHubhttps://github.com/MartijnR
--
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/groups/opt_out.
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
--
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/groups/opt_out.
--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/OrIpNbrWvtY/unsubscribe?hl=en
.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Enketo http://enketo.org | LinkedIn
http://www.linkedin.com/in/martijnvanderijdt/ |
GitHubhttps://github.com/MartijnR