Turn off SSL redirection on Aggregate

Support
1

Hello,

I'm trying out ODK and have setup the Aggregate web-app on google app
engine. I'm trying to use my own domain name for the Aggregate URL (instead
of xyz.appspot.com). My own domain name is hosted on a shared server
(bluehost) and hence, I cannot install any kind of self-signed SSL
certificate on that server, unless I buy a dedicated IP address for them
(that costs $, and it is something that I don't need).

Hence, my question is - is there a way to turn off SSL redirection on the
Aggreagte app.

The specifics are as follows:
I've setup Aggregate on energy-readings.appspot.com (which redirects
to https://energy-readings.appspot.com). In my GAE account, I've also setup
the domain energy.urbansensors.net as a domain which is mapped to this
appspot url. But when I go to http://energy.urbansensors.net -- the
Aggreate app is automatically trying to redirect to
https://energy.urbansensors.net

Is there a way for me to disabled this redirection?

Thank you,

Ronak

2

First, please be aware that if you are using http:, all your data is
visible to anyone with a network sniffer. I.e., it is sent "in the clear".
And http makes it easier for malicious parties to trick your ODK Collect
clients to submit their data elsewhere.

You might want to look at Google Apps Domain hosting for your domain name.
They might provide you with an SSL certificate if you run entirely on
Google infrastructure.

Otherwise, yes, you can configure ODK Aggregate to not use SSL (use only
http: connections).

After the ODK Aggregate installer generates the ODK Aggregate directory,
exit the installer without launching the upload script.

Then change to this directory:

ODK Aggregate/ODKAggregate/WEB-INF/lib

You will need to edit the contents of ODKAggregate-settings.jar

The easiest way to do this is using 7-Zip ( http://www.7-zip.org/ )

Open this jar file using 7-Zip. Then select security.properties within
it, right-click, Edit

search for the 2 lines:

security.server.secureChannelType=REQUIRES_SECURE_CHANNEL

and

security.server.channelType=REQUIRES_SECURE_CHANNEL

change the REQUIRES_SECURE_CHANNEL to REQUIRES_INSECURE_CHANNEL

Save, close the editor (Notepad).
Click 'Yes' to save these changes into the ODKAggregate-settings.jar
Exit 7-Zip.

Now upload the server to Google AppEngine by double-clicking

ODK Aggregate/uploadAggregateToAppEngine.hta

Similar steps also apply when running on Mac OSX or Linux.

See
http://code.google.com/p/opendatakit/wiki/AggregateDeploymentConfigurationfor
more info on the configuration files.

3

Hello Mitch,
Thank you indeed for your detailed reply and the steps to turn-off SSL. I
will try them out very soon.

I understand the concern and vulnerability you've described of using http
over https, and that data will be sent in the clear. We are fine with that,
as we intend to make all the data open in any case. We of course don't want
our ODK clients being tricked into submitting our data elsewhere, but given
that we are currently working with energy meter readings, I doubt anyone
would be that interested in our data to setup a man-in-the-middle attack on
our tiny infrastructure :slight_smile:

The reason I'd prefer to have the option of turning SSL on or off, is that
on the ODK client side, I'd be concerned about the power consumption that
happens for using HTTPS over HTTP on the Android client side. We are
looking to collect energy readings of thousands of meters in the city of
Mumbai. And we have very low-end Android tablets (due to cost constraints)
-- and the power on those tablets/phones runs out within an hour and half.
Hence, I'm closely looking at every mW that is spent on the device.

We've infact, even considered using alternate protocols in our other
Android apps - http://stephendnicholas.com/archives/1217.

In case ODK is interested in supporting any non-HTTP protocols (both on
client and server side), do let me know as we've been researching non-HTTP
protocols for Android over the past one year (all from the power profiling
perspective).

Regards,
Ronak Sutaria

··· On Monday, 5 August 2013 22:53:01 UTC+5:30, Mitch Sundt wrote: > > First, please be aware that if you are using http:, all your data is > visible to anyone with a network sniffer. I.e., it is sent "in the clear". > And http makes it easier for malicious parties to trick your ODK Collect > clients to submit their data elsewhere. > > You might want to look at Google Apps Domain hosting for your domain name. > They might provide you with an SSL certificate if you run entirely on > Google infrastructure. > > Otherwise, yes, you can configure ODK Aggregate to not use SSL (use only > http: connections). > > After the ODK Aggregate installer generates the ODK Aggregate directory, > exit the installer without launching the upload script. > > Then change to this directory: > > ODK Aggregate/ODKAggregate/WEB-INF/lib > > You will need to edit the contents of ODKAggregate-settings.jar > > The easiest way to do this is using 7-Zip ( http://www.7-zip.org/ ) > > Open this jar file using 7-Zip. Then select *security.properties* within > it, right-click, Edit > > search for the 2 lines: > > security.server.secureChannelType=REQUIRES_SECURE_CHANNEL > > and > > security.server.channelType=REQUIRES_SECURE_CHANNEL > > change the REQUIRES_SECURE_CHANNEL to REQUIRES_INSECURE_CHANNEL > > Save, close the editor (Notepad). > Click 'Yes' to save these changes into the ODKAggregate-settings.jar > Exit 7-Zip. > > > Now upload the server to Google AppEngine by double-clicking > > ODK Aggregate/uploadAggregateToAppEngine.hta > > Similar steps also apply when running on Mac OSX or Linux. > > See > http://code.google.com/p/opendatakit/wiki/AggregateDeploymentConfigurationfor more info on the configuration files. > > > > > > > >
4

Hi Ronak,

If you're concerned about power consumption, why send data during
data-collection? Most set-ups turn off all networking while collecting data
so that they consume a minimum of power. Then, in the evening, they can
plug in to (a) recharge and (b) send data. You can also skip the sim cards
altogether in most data-collector devices; you could have each team's
supervisor have a sim in his or her device, broadcast a mobile hot spot in
the evening, and have the team send their data via wifi through that hot
spot.

If you yourself have been doing power profiling (along the lines of
http://stephendnicholas.com/archives/1217), and if you wouldn't mind doing
a bit more, please let me know. We've dramatically reduced the memory usage
for our SurveyCTO version of Collect, and our lower-memory version may also
consume less power -- we don't actually know. If it's easy for you to
profile it, it would be useful to know whether the reduced memory usage
also reduces power consumption. If so, it would be a strong argument in
favor of working those reductions into the public version of ODK Collect.
(It requires non-trivial changes to JavaRosa, but those changes may be
worth it.)

Thanks,

Chris

··· On Mon, Aug 5, 2013 at 11:09 PM, rsutaria wrote:

Hello Mitch,
Thank you indeed for your detailed reply and the steps to turn-off SSL. I
will try them out very soon.

I understand the concern and vulnerability you've described of using http
over https, and that data will be sent in the clear. We are fine with that,
as we intend to make all the data open in any case. We of course don't want
our ODK clients being tricked into submitting our data elsewhere, but given
that we are currently working with energy meter readings, I doubt anyone
would be that interested in our data to setup a man-in-the-middle attack on
our tiny infrastructure :slight_smile:

The reason I'd prefer to have the option of turning SSL on or off, is that
on the ODK client side, I'd be concerned about the power consumption that
happens for using HTTPS over HTTP on the Android client side. We are
looking to collect energy readings of thousands of meters in the city of
Mumbai. And we have very low-end Android tablets (due to cost constraints)
-- and the power on those tablets/phones runs out within an hour and half.
Hence, I'm closely looking at every mW that is spent on the device.

We've infact, even considered using alternate protocols in our other
Android apps - http://stephendnicholas.com/archives/1217.

In case ODK is interested in supporting any non-HTTP protocols (both on
client and server side), do let me know as we've been researching non-HTTP
protocols for Android over the past one year (all from the power profiling
perspective).

Regards,
Ronak Sutaria

On Monday, 5 August 2013 22:53:01 UTC+5:30, Mitch Sundt wrote:

First, please be aware that if you are using http:, all your data is
visible to anyone with a network sniffer. I.e., it is sent "in the clear".
And http makes it easier for malicious parties to trick your ODK Collect
clients to submit their data elsewhere.

You might want to look at Google Apps Domain hosting for your domain
name. They might provide you with an SSL certificate if you run entirely on
Google infrastructure.

Otherwise, yes, you can configure ODK Aggregate to not use SSL (use only
http: connections).

After the ODK Aggregate installer generates the ODK Aggregate directory,
exit the installer without launching the upload script.

Then change to this directory:

ODK Aggregate/ODKAggregate/WEB-**INF/lib

You will need to edit the contents of ODKAggregate-settings.jar

The easiest way to do this is using 7-Zip ( http://www.7-zip.org/ )

Open this jar file using 7-Zip. Then select security.properties within
it, right-click, Edit

search for the 2 lines:

security.server.**secureChannelType=REQUIRES_**SECURE_CHANNEL

and

security.server.channelType=**REQUIRES_SECURE_CHANNEL

change the REQUIRES_SECURE_CHANNEL to REQUIRES_INSECURE_CHANNEL

Save, close the editor (Notepad).
Click 'Yes' to save these changes into the ODKAggregate-settings.jar
Exit 7-Zip.

Now upload the server to Google AppEngine by double-clicking

ODK Aggregate/**uploadAggregateToAppEngine.hta

Similar steps also apply when running on Mac OSX or Linux.

See http://code.google.com/p/**opendatakit/wiki/**
AggregateDeploymentConfigurati**onhttp://code.google.com/p/opendatakit/wiki/AggregateDeploymentConfigurationfor more info on the configuration files.

--
--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

5

Hello Chris,

ODK is indeed very well designed and architected. I've started using it
only three days ago, and was not fully familiar with all it's features.
Your suggestion is correct, and we won't be sending the forms as soon as
they are filled, but later in the day send it via the "Send Finalized
Forms" feature. I should have studied the app more closely before raising
the https concern.

Yes, we might be able to help with giving you an idea of the memory usage
of the app and the power consumed during a fixed time-period. There are
certain internal OS APIs available which provide the power measurements per
app-UID.
http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/2.2_r1.1/com/android/internal/os/PowerProfile.java

We've implemented certain APIs as well as acquired certain tools which we
are currently using to tell us the mW consumption for network activity of
an App. We can also do memory usage profiling and compare it with the power
consumption. Let me know the link to your app and the kind of tests you'd
like for me to run on the app. I'll give you a summary of the memory
consumption vs power profiling of the same.

Thanks,
Ronak

··· On Tuesday, 6 August 2013 16:10:20 UTC+5:30, Christopher Robert wrote: > > Hi Ronak, > > If you're concerned about power consumption, why send data during > data-collection? Most set-ups turn off all networking while collecting data > so that they consume a minimum of power. Then, in the evening, they can > plug in to (a) recharge and (b) send data. You can also skip the sim cards > altogether in most data-collector devices; you could have each team's > supervisor have a sim in his or her device, broadcast a mobile hot spot in > the evening, and have the team send their data via wifi through that hot > spot. > > If you yourself have been doing power profiling (along the lines of > http://stephendnicholas.com/archives/1217), and if you wouldn't mind > doing a bit more, please let me know. We've dramatically reduced the memory > usage for our SurveyCTO version of Collect, and our lower-memory version > may also consume less power -- we don't actually know. If it's easy for you > to profile it, it would be useful to know whether the reduced memory usage > also reduces power consumption. If so, it would be a strong argument in > favor of working those reductions into the public version of ODK Collect. > (It requires non-trivial changes to JavaRosa, but those changes may be > worth it.) > > Thanks, > > Chris > > On Mon, Aug 5, 2013 at 11:09 PM, rsutaria <rsut...@gmail.com wrote: > >> Hello Mitch, >> Thank you indeed for your detailed reply and the steps to turn-off SSL. I >> will try them out very soon. >> >> I understand the concern and vulnerability you've described of using http >> over https, and that data will be sent in the clear. We are fine with that, >> as we intend to make all the data open in any case. We of course don't want >> our ODK clients being tricked into submitting our data elsewhere, but given >> that we are currently working with energy meter readings, I doubt anyone >> would be that interested in our data to setup a man-in-the-middle attack on >> our tiny infrastructure :-) >> >> The reason I'd prefer to have the option of turning SSL on or off, is >> that on the ODK client side, I'd be concerned about the power consumption >> that happens for using HTTPS over HTTP on the Android client side. We are >> looking to collect energy readings of thousands of meters in the city of >> Mumbai. And we have very low-end Android tablets (due to cost constraints) >> -- and the power on those tablets/phones runs out within an hour and half. >> Hence, I'm closely looking at every mW that is spent on the device. >> >> We've infact, even considered using alternate protocols in our other >> Android apps - http://stephendnicholas.com/archives/1217. >> >> In case ODK is interested in supporting any non-HTTP protocols (both on >> client and server side), do let me know as we've been researching non-HTTP >> protocols for Android over the past one year (all from the power profiling >> perspective). >> >> Regards, >> Ronak Sutaria >> >> >> >> On Monday, 5 August 2013 22:53:01 UTC+5:30, Mitch Sundt wrote: >>> >>> First, please be aware that if you are using http:, all your data is >>> visible to anyone with a network sniffer. I.e., it is sent "in the clear". >>> And http makes it easier for malicious parties to trick your ODK Collect >>> clients to submit their data elsewhere. >>> >>> You might want to look at Google Apps Domain hosting for your domain >>> name. They might provide you with an SSL certificate if you run entirely on >>> Google infrastructure. >>> >>> Otherwise, yes, you can configure ODK Aggregate to not use SSL (use only >>> http: connections). >>> >>> After the ODK Aggregate installer generates the ODK Aggregate directory, >>> exit the installer without launching the upload script. >>> >>> Then change to this directory: >>> >>> ODK Aggregate/ODKAggregate/WEB-**INF/lib >>> >>> You will need to edit the contents of ODKAggregate-settings.jar >>> >>> The easiest way to do this is using 7-Zip ( http://www.7-zip.org/ ) >>> >>> Open this jar file using 7-Zip. Then select *security.properties*within it, right-click, Edit >>> >>> search for the 2 lines: >>> >>> security.server.**secureChannelType=REQUIRES_**SECURE_CHANNEL >>> >>> and >>> >>> security.server.channelType=**REQUIRES_SECURE_CHANNEL >>> >>> change the REQUIRES_SECURE_CHANNEL to REQUIRES_INSECURE_CHANNEL >>> >>> Save, close the editor (Notepad). >>> Click 'Yes' to save these changes into the ODKAggregate-settings.jar >>> Exit 7-Zip. >>> >>> >>> Now upload the server to Google AppEngine by double-clicking >>> >>> ODK Aggregate/**uploadAggregateToAppEngine.hta >>> >>> Similar steps also apply when running on Mac OSX or Linux. >>> >>> See http://code.google.com/p/**opendatakit/wiki/** >>> AggregateDeploymentConfigurati**onfor more info on the configuration files. >>> >>> >>> >>> >>> >>> >>> >>> -- >> -- >> Post: opend...@googlegroups.com >> Unsubscribe: opendatakit...@googlegroups.com >> Options: http://groups.google.com/group/opendatakit?hl=en >> >> --- >> You received this message because you are subscribed to the Google Groups >> "ODK Community" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to opendatakit...@googlegroups.com . >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > >
6

Hi Ronak,

Thanks for this information!

It looks like we will need to build the power-profiling into our version of
Collect, in order to do this. We will take a look into it, and may bother
you with a question or two if you don't mind -- but we won't bother you to
help with the profiling. We will report back and suggest changes if our
JavaRosa tweaks improve both memory and power consumption.

Thanks again,

Chris

··· On Tue, Aug 6, 2013 at 11:52 PM, rsutaria wrote:

Hello Chris,

ODK is indeed very well designed and architected. I've started using it
only three days ago, and was not fully familiar with all it's features.
Your suggestion is correct, and we won't be sending the forms as soon as
they are filled, but later in the day send it via the "Send Finalized
Forms" feature. I should have studied the app more closely before raising
the https concern.

Yes, we might be able to help with giving you an idea of the memory usage
of the app and the power consumed during a fixed time-period. There are
certain internal OS APIs available which provide the power measurements per
app-UID.
http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/2.2_r1.1/com/android/internal/os/PowerProfile.java

We've implemented certain APIs as well as acquired certain tools which we
are currently using to tell us the mW consumption for network activity of
an App. We can also do memory usage profiling and compare it with the power
consumption. Let me know the link to your app and the kind of tests you'd
like for me to run on the app. I'll give you a summary of the memory
consumption vs power profiling of the same.

Thanks,
Ronak

On Tuesday, 6 August 2013 16:10:20 UTC+5:30, Christopher Robert wrote:

Hi Ronak,

If you're concerned about power consumption, why send data during
data-collection? Most set-ups turn off all networking while collecting data
so that they consume a minimum of power. Then, in the evening, they can
plug in to (a) recharge and (b) send data. You can also skip the sim cards
altogether in most data-collector devices; you could have each team's
supervisor have a sim in his or her device, broadcast a mobile hot spot in
the evening, and have the team send their data via wifi through that hot
spot.

If you yourself have been doing power profiling (along the lines of
http://stephendnicholas.com/**archives/1217http://stephendnicholas.com/archives/1217),
and if you wouldn't mind doing a bit more, please let me know. We've
dramatically reduced the memory usage for our SurveyCTO version of Collect,
and our lower-memory version may also consume less power -- we don't
actually know. If it's easy for you to profile it, it would be useful to
know whether the reduced memory usage also reduces power consumption. If
so, it would be a strong argument in favor of working those reductions into
the public version of ODK Collect. (It requires non-trivial changes to
JavaRosa, but those changes may be worth it.)

Thanks,

Chris

On Mon, Aug 5, 2013 at 11:09 PM, rsutaria rsut...@gmail.com wrote:

Hello Mitch,
Thank you indeed for your detailed reply and the steps to turn-off SSL.
I will try them out very soon.

I understand the concern and vulnerability you've described of using
http over https, and that data will be sent in the clear. We are fine with
that, as we intend to make all the data open in any case. We of course
don't want our ODK clients being tricked into submitting our data
elsewhere, but given that we are currently working with energy meter
readings, I doubt anyone would be that interested in our data to setup a
man-in-the-middle attack on our tiny infrastructure :slight_smile:

The reason I'd prefer to have the option of turning SSL on or off, is
that on the ODK client side, I'd be concerned about the power consumption
that happens for using HTTPS over HTTP on the Android client side. We are
looking to collect energy readings of thousands of meters in the city of
Mumbai. And we have very low-end Android tablets (due to cost constraints)
-- and the power on those tablets/phones runs out within an hour and half.
Hence, I'm closely looking at every mW that is spent on the device.

We've infact, even considered using alternate protocols in our other
Android apps - http://stephendnicholas.com/**archives/1217http://stephendnicholas.com/archives/1217
.

In case ODK is interested in supporting any non-HTTP protocols (both on
client and server side), do let me know as we've been researching non-HTTP
protocols for Android over the past one year (all from the power profiling
perspective).

Regards,
Ronak Sutaria

On Monday, 5 August 2013 22:53:01 UTC+5:30, Mitch Sundt wrote:

First, please be aware that if you are using http:, all your data is
visible to anyone with a network sniffer. I.e., it is sent "in the clear".
And http makes it easier for malicious parties to trick your ODK Collect
clients to submit their data elsewhere.

You might want to look at Google Apps Domain hosting for your domain
name. They might provide you with an SSL certificate if you run entirely on
Google infrastructure.

Otherwise, yes, you can configure ODK Aggregate to not use SSL (use
only http: connections).

After the ODK Aggregate installer generates the ODK Aggregate
directory, exit the installer without launching the upload script.

Then change to this directory:

ODK Aggregate/ODKAggregate/WEB-INF/lib

You will need to edit the contents of ODKAggregate-settings.jar

The easiest way to do this is using 7-Zip ( http://www.7-zip.org/ )

Open this jar file using 7-Zip. Then select security.propertieswithin it, right-click, Edit

search for the 2 lines:

security.server.secureChannelType=REQUIRES_**SECURE_CHANNEL

and

security.server.channelType=REQUIRES_SECURE_CHANNEL

change the REQUIRES_SECURE_CHANNEL to REQUIRES_INSECURE_CHANNEL

Save, close the editor (Notepad).
Click 'Yes' to save these changes into the ODKAggregate-settings.jar
Exit 7-Zip.

Now upload the server to Google AppEngine by double-clicking

ODK Aggregate/uploadAggregateToAppEngine.hta

Similar steps also apply when running on Mac OSX or Linux.

See http://code.google.com/p/**opend**atakit/wiki/**AggregateDeploymen*
*tConfigurati**onhttp://code.google.com/p/opendatakit/wiki/AggregateDeploymentConfigurationfor more info on the configuration files.

--
--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@**googlegroups.com

Options: http://groups.google.com/**group/opendatakit?hl=enhttp://groups.google.com/group/opendatakit?hl=en

You received this message because you are subscribed to the Google
Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit...@**googlegroups.com.

For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
.

7

conseguiste quitar los SSL de aggregate?

8

Alguna forma útil para configurar el redireccionamiento de aggregate. aun tengo ese problema no lo puedo solucionar