SQLMAP unable to identify injection point

[snipercatz]

What's the problem (or question)?

I'm going to break my question down into two parts. First with regards to SQLMAP specifically, the second part going into the manual exploitation problems I'm experiencing (for anyone who's willing to help).
SQLMAP is unable to identify a confirmed sqli vulnerability.
The vulnerability is MYSQL error based. I saved the following request to a txt file and fed it to sqlmap using the '-r' switch. Through manual means I determined it's not necessary to update the csrf cookie.

sqlmap -r request.txt --random-agent --level 5 --risk 3 --dbms mysql -v 6

Request:

POST /blah/login/verify HTTP/1.1
Content-Length: 84
Content-Type: application/x-www-form-urlencoded
Cookie: PHPSESSID=c2nlsn3gel9c023mb8lu58di44; csrf_cookie_name=a565487fecb389397156de204f2cbd74;
Host: www.website.org
Connection: Keep-alive
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.21 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.21
Accept: /

csrf_test_name=a565487fecb389397156de204f2cbd74&password=goodpassword&username=1*

[14:22:45] [DEBUG] declared web page charset 'iso-8859-1'
[14:22:45] [TRAFFIC IN] HTTP redirect [#1] (301 Moved Permanently):
Content-length: 262
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/7.0.31
Connection: close
Location: https://www.website.org/blah/login/verify
Date: Mon, 18 Feb 2019 20:28:33 GMT
Content-type: text/html; charset=iso-8859-1

<title>301 Moved Permanently</title>

Moved Permanently

The document has moved here.

sqlmap got a 301 redirect to 'https://www.website.org/blah/login/verify'. Do you want to follow? [Y/n] n
[14:22:48] [TRAFFIC IN] HTTP response [#1] (301 Moved Permanently):
Content-length: 262
Uri: https://www.website.org/blah/login/verify
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/7.0.31
Connection: close
Location: https://www.website.org/blah/login/verify
Date: Mon, 18 Feb 2019 20:28:33 GMT
Content-type: text/html; charset=iso-8859-1

<title>301 Moved Permanently</title>

Moved Permanently

The document has moved here.

[14:22:48] [INFO] testing if the target URL content is stable
[14:22:48] [TRAFFIC OUT] HTTP request [#2]:
POST /blah/login/verify HTTP/1.1
Host: www.website.org
Referer: http://www.website.org:80/blah/login/verify
Accept-encoding: gzip,deflate
Cookie: PHPSESSID=c2nlsn3gel9c023mb8lu58di44; csrf_cookie_name=a565487fecb389397156de204f2cbd74;
Content-type: application/x-www-form-urlencoded
Accept: /
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.21 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.21
Content-length: 80
Connection: close

csrf_test_name=a565487fecb389397156de204f2cbd74&password=goodpassword&username=1

[14:22:48] [TRAFFIC IN] HTTP redirect [#2] (301 Moved Permanently):
Content-length: 262
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/7.0.31
Connection: close
Location: https://www.website.org/blah/login/verify
Date: Mon, 18 Feb 2019 20:28:37 GMT
Content-type: text/html; charset=iso-8859-1

<title>301 Moved Permanently</title>

Moved Permanently

The document has moved here.

So as you can see, rather than identifying the injection point, SQLMAP is just following the redirection, even though I told it not to. Here is the response I receive when I perform the injection manually.

Response:
A Database Error Occurred
Error Number: 1064

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '1'') && password='a0d540a78cd61daa5fb872ac29272c00' && activate='1'' at line 1

select id,fname,lname,uname,password from tpuser where (uname='1'' || email='1'') && password='a0d540a78cd61daa5fb872ac29272c00' && activate='1'

Filename: models/blah/Tp_common_functions_model.php

Line Number: 94

Now on to my question about manual exploitation (I'm still new to this so bear with me). I'm having a hard time trying to figure out the logic being implemented by the application. From the response I can deduce the following:
There is a table named tpuser with columns id, fname, lname, uname, and password.
There are an unequal number of quotation marks surrounding uname and email, which is what's triggering the vulnerability.
The password 'goodpassword' is being MD5 hashed when returned by the application

My question is:
What is it about adding a single ' at the end of 'csrf_test_name=a565487fecb389397156de204f2cbd74&password=goodpassword&username=1' that would cause the application to dump the information about tpuser and it's column names without the presence of a query constructed to pull that information? And in this context, how would I construct a query to dump the data in the columns?

What are the running context details?

I'm using Kali linux as my OS
I've made sure to update both Kali and SQLMAP to it's latest release.

Thanks for any help.

[stamparm]

This has nothing to do with manual exploitation. Please learn some stuff before claiming this kind of non sense.

Using a single-quote doesn't prove anything. Also, it doesn't make you able to "manually" inject anything.

Sorry, this is not right place to do this kind of stuff. Google should help you more

[snipercatz]

I think I didn't do a good job explaining what I'm talking about with regards to the manual injection, part of my ? but it's not what you think I was asking.
But I claim no nonsense. I provided the proof. I've already manually exploited the vulnerability and extracted data from several different tables . The data that's being returned isn't what I expected though based on the queries I'm issuing.
So since the vulnerability CAN be manually exploited, but SQLMAP CAN'T find the vulnerability....idk, I guess that makes me incompetent. My bad.

[stamparm]

Can you share "private" details to miroslav@sqlmap.org so I could take a look? From your report I can't conclude anything than that you've successfully provoked a DBMS error message <- this doesn't prove anything as I've already stated