Reporter error code 401 - wiki correction?

[littleguy77]

Reporter error code 401 - wiki correction?

[littleguy77]

In case it went to your junk folder, I replied to your email with more details on this.

[KevinGaudin]

I got your mail, had a look to your DB and logs, and have been thinking about it since.

Unless it changed recently, CouchDB's security model is the following (Matt Woodward's blog post is the best summary of this topic):

• default (admin party): anyone can read / write everything
• once an admin is set: only admins can write _design/* documents - anyone can read / write in DBs
• once a member (name or role) is set on a DB, only members can read data from the DB and anyone can write in the DB
• write access rights can be defined in a specific validate_doc_update function where we can check details from the user context (role, name or anything else). This allows a finer grain of validation, depending on the type of document to be stored for example.

So, in your case, I don't understand how adding the "reporter" role as a database member could have allowed your report user to PUT reports in your Database. There might have been something else... are you sure that the attempts that were receiving 401 errors were made with the correct reporter credentials in your ACRA configuration ?

[littleguy77]

I removed "reporter" role from the member list and AFAIK am following the wiki instructions to the letter. I can log in manually to futon with the reporter credentials, so it doesn't look like a password typo. I continue to get a 401 error:

02-21 20:49:17.979: D/ACRA(28034): Connect to https://paulscode.iriscouch.com/acra-mupen64plusae/_design/acra-storage/_update/report
02-21 20:49:18.059: D/ACRA(28034): Sending request to https://paulscode.iriscouch.com/acra-mupen64plusae/_design/acra-storage/_update/report/f57ca54a-24a1-457d-859f-df666dc5b673
02-21 20:49:18.389: D/dalvikvm(28034): GC_CONCURRENT freed 1106K, 11% free 11030K/12284K, paused 2ms+4ms, total 34ms
02-21 20:49:18.589: W/DefaultRequestDirector(28034): Authentication error: Unable to respond to any of these challenges: {}
02-21 20:49:18.599: E/ACRA(28034): Failed to send crash report for 1361497226000-approved.stacktrace
02-21 20:49:18.599: E/ACRA(28034): org.acra.sender.ReportSenderException: Error while sending JSON report via Http PUT
02-21 20:49:18.599: E/ACRA(28034):  at org.acra.sender.HttpSender.send(HttpSender.java:181)
02-21 20:49:18.599: E/ACRA(28034):  at org.acra.SendWorker.sendCrashReport(SendWorker.java:178)
02-21 20:49:18.599: E/ACRA(28034):  at org.acra.SendWorker.checkAndSendReports(SendWorker.java:141)
02-21 20:49:18.599: E/ACRA(28034):  at org.acra.SendWorker.run(SendWorker.java:77)
02-21 20:49:18.599: E/ACRA(28034): Caused by: java.io.IOException: Host returned error code 401
02-21 20:49:18.599: E/ACRA(28034):  at org.acra.util.HttpRequest.send(HttpRequest.java:139)
02-21 20:49:18.599: E/ACRA(28034):  at org.acra.sender.HttpSender.send(HttpSender.java:178)
02-21 20:49:18.599: E/ACRA(28034):  ... 3 more

One time I did get a different error. In case it helps:

02-21 20:40:27.209: E/ACRA(28034): Failed to send crash report for 1361497226000-approved.stacktrace
02-21 20:40:27.209: E/ACRA(28034): org.acra.sender.ReportSenderException: Error while sending JSON report via Http PUT
02-21 20:40:27.209: E/ACRA(28034):  at org.acra.sender.HttpSender.send(HttpSender.java:181)
02-21 20:40:27.209: E/ACRA(28034):  at org.acra.SendWorker.sendCrashReport(SendWorker.java:178)
02-21 20:40:27.209: E/ACRA(28034):  at org.acra.SendWorker.checkAndSendReports(SendWorker.java:141)
02-21 20:40:27.209: E/ACRA(28034):  at org.acra.SendWorker.run(SendWorker.java:77)
02-21 20:40:27.209: E/ACRA(28034): Caused by: javax.net.ssl.SSLException: Read error: ssl=0x67480e38: I/O error during system call, Connection reset by peer
02-21 20:40:27.209: E/ACRA(28034):  at org.apache.harmony.xnet.provider.jsse.NativeCrypto.SSL_read(Native Method)
02-21 20:40:27.209: E/ACRA(28034):  at org.apache.harmony.xnet.provider.jsse.OpenSSLSocketImpl$SSLInputStream.read(OpenSSLSocketImpl.java:664)
02-21 20:40:27.209: E/ACRA(28034):  at org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:103)
02-21 20:40:27.209: E/ACRA(28034):  at org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:191)
02-21 20:40:27.209: E/ACRA(28034):  at org.apache.http.impl.conn.DefaultResponseParser.parseHead(DefaultResponseParser.java:82)
02-21 20:40:27.209: E/ACRA(28034):  at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:174)
02-21 20:40:27.209: E/ACRA(28034):  at org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:180)
02-21 20:40:27.209: E/ACRA(28034):  at org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:235)
02-21 20:40:27.209: E/ACRA(28034):  at org.apache.http.impl.conn.AbstractClientConnAdapter.receiveResponseHeader(AbstractClientConnAdapter.java:259)
02-21 20:40:27.209: E/ACRA(28034):  at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:279)
02-21 20:40:27.209: E/ACRA(28034):  at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:121)
02-21 20:40:27.209: E/ACRA(28034):  at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:428)
02-21 20:40:27.209: E/ACRA(28034):  at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:555)
02-21 20:40:27.209: E/ACRA(28034):  at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:487)
02-21 20:40:27.209: E/ACRA(28034):  at org.acra.util.HttpRequest.send(HttpRequest.java:132)
02-21 20:40:27.209: E/ACRA(28034):  at org.acra.sender.HttpSender.send(HttpSender.java:178)
02-21 20:40:27.209: E/ACRA(28034):  ... 3 more

[littleguy77]

I also tried using regular http: instead of https: in my Java app. That also didn't seem to help.

Do I need to use a salted/hashed password in the Java annotation? It's just plain text right now.

I just tried using the admin credentials instead in my app. Now I get a 403 error:

02-21 20:53:55.399: E/ACRA(31715): Failed to send crash report for 1361497226000-approved.stacktrace
02-21 20:53:55.399: E/ACRA(31715): org.acra.sender.ReportSenderException: Error while sending JSON report via Http PUT
02-21 20:53:55.399: E/ACRA(31715):  at org.acra.sender.HttpSender.send(HttpSender.java:181)
02-21 20:53:55.399: E/ACRA(31715):  at org.acra.SendWorker.sendCrashReport(SendWorker.java:178)
02-21 20:53:55.399: E/ACRA(31715):  at org.acra.SendWorker.checkAndSendReports(SendWorker.java:141)
02-21 20:53:55.399: E/ACRA(31715):  at org.acra.SendWorker.run(SendWorker.java:77)
02-21 20:53:55.399: E/ACRA(31715): Caused by: java.io.IOException: Host returned error code 403
02-21 20:53:55.399: E/ACRA(31715):  at org.acra.util.HttpRequest.send(HttpRequest.java:139)
02-21 20:53:55.399: E/ACRA(31715):  at org.acra.sender.HttpSender.send(HttpSender.java:178)
02-21 20:53:55.399: E/ACRA(31715):  ... 3 more

I tried manually deleting the cached stacktrace files in the app's data directory, but that didn't change the 403 error.

[littleguy77]

For now I'm going to add reporter back as a member to the acra-storage db, so that the my team can start using it. In case you look into my db and are confused.

[littleguy77]

Hmmm, from what I'm reading, there is no kind of "write-only" user as of couchdb 1.2. I don't think Matt Woodward's post is correct when he says anonymous writes are allowed on a db with readers assigned.

Here's a (rather old) bug report but it does seem to refer to version 1.2:
https://issues.apache.org/jira/browse/COUCHDB-1287

This is consistent with what I've read on stackoverflow as well: a user can either (read and write) or nothing. With a validation function you can effectively achieve read-only access, as you well know. But there's no built-in mechanism for write-only access from what I've seen so far.

I'm sure you've read into this much more than me, so if you have other references besides Woodward, I'd be curious to read them.

[littleguy77]

What about creating an encrypted database that the reporter can write (and read). Then somehow this gets replicated and unencrypted to another database which only the reader can read.

Another idea out the wazoo: Can the validator from one database write to another database? The reporter's database validator would just validate and forward the information to the "real" destination db (which perhaps has a different validator).

[halkeye]

I had the exact same problem tonight. Followed the instructions with iriscouch. Originally had ["reader"] Under Security>members>Roles, got the same 401 error. Switch it to ["reader","reporter"] and things work fine.

[KevinGaudin]

I'm sorry, I've been misled by the previously cited blog post.

I just figured out that my own reporter user was also a reader.

This is really embarrassing, I did not want reporter users to be able to
read all data.
Le 23 févr. 2013 10:21, "Gavin" [email protected] a écrit :

I had the exact same problem tonight. Followed the instructions with
iriscouch. Originally had ["reader"] Under Security>members>Roles, got
the same 401 error. Switch it to ["reader","reporter"] and things work
fine.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-13987430.

[halkeye]

jquery.couchLogin.js doesn't seem very extendable, but couldn't we change script/app.js so that it checks r.userCtx.roles to see if it contains reader and if not, log out? or is that too hacky?

I guess it doesn't actually fix people logging in with the api and accessing it that way.

[KevinGaudin]

The problem is that someone who gets the reporter user credentials will
always be able to query the whole database content through the REST API.

I think that all we can do for the moment is warn devs that their
credentials should note be commited in public source repositories and
reporting should be done over https.
Le 25 févr. 2013 04:52, "Gavin" [email protected] a écrit :

jquery.couchLogin.js doesn't seem very extendable, but couldn't we change
script/app.js so that it checks r.userCtx.roles to see if it contains
reader and if not, log out? or is that too hacky?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-14024565.

[halkeye]

I saw you posted on https://issues.apache.org/jira/browse/COUCHDB-1287?focusedCommentId=13585238&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13585238

I've voted up the issue as well.

[littleguy77]

... their credentials should not be commited in public source repositories ...

Any good ideas for a clean and simple way to do that with an open-source project on github? My first thought was to create a class that doesn't get committed to the repository (but would that violate GPL?):

UncommittedClass.java

public class UncommittedClass
{
    public static final String acraAuthLogin = "reportername"
    public static final String acraAuthPassword = "reporterpassword";
}

MyApp.java

@ReportsCrashes
(
    formKey = "",
    formUri = "https://myapp.iriscouch.com/acra-myapp/_design/acra-storage/_update/report",
    reportType = Type.JSON,
    httpMethod = Method.PUT,
    formUriBasicAuthLogin = UncommittedClass.acraAuthLogin,
    formUriBasicAuthPassword = UncommittedClass.acraAuthPassword 
)
public class MyApp extends android.app.Application
{
    @Override
    public void onCreate()
    {
        super.onCreate();

        // Initialize ACRA crash reporting system
        ACRA.init( this );
    }
}

You could still get the strings by decompiling but at least it wouldn't be hanging out in the wind for all to see.

[KevinGaudin]

Yes @littleguy77 , I think this can be a simple and sufficient way. We should include the formUri as well in the UncommittedClass.

[jarro]

Is it potentially possible to create an insert only user, or do we need to handle this security issue with a small proxy app to keep the user/pass out of the app?

[KevinGaudin]

I updated the wiki with:

• the usage of Cloudant and its proprietary security layer which allows the creation of write only users (API Keys)
• some examples on how to setup a reverse proxy with apache httpd, nginx or a php script.