search

ACRA / acralyzer

Open source backend for ACRA reports.
GNU General Public License v3.0
489 stars 90 forks source link

Reporter error code 401 - wiki correction? #4

Closed littleguy77 closed 11 years ago

littleguy77 commented 11 years ago

I noticed you added the instructions to the wiki to include the "reader" role as a member of the "acra-foo" database. However, when I do this, I can no longer submit reports (401 error). I added the "reporter" role as a second member of "acra-foo" and that allowed me to submit reports again. But is that the correct solution? Did I miss a step somewhere in the wiki?

littleguy77 commented 11 years ago

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

KevinGaudin commented 11 years ago

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):

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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" notifications@github.com 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/ACRA/acralyzer/issues/4#issuecomment-13987430.

halkeye commented 11 years ago

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 commented 11 years ago

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" notifications@github.com 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/ACRA/acralyzer/issues/4#issuecomment-14024565.

halkeye commented 11 years ago

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 commented 11 years ago

... 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 commented 11 years ago

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

jarro commented 11 years ago

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 commented 11 years ago

I updated the wiki with: