The Issue:
It appears there is some sort of encoding/decoding issue going on with flask-bcrypt for my Mac. I'd like to know if there is an easy solution to fix this so I can run my local with a similar setup to my Heroku version.
Comparison:
Local
If I use .decode("utf-8") with generate_password_hash it returns AttributeError: 'str' object has no attribute 'decode'. Without decode, it saves my password to the database properly and I'm able to login with no issues.
When I test bcrypt.generate_password_hash [without decode] in terminal on local it
returns like '$2b$12$yTBsCi.....`
Heroku
If I use .decode("utf-8") with generate_password_hash it saves to the database properly and I"m able to login. If I don't use decode("utf-8"), it saves the password incorrectly (something like: \x243261243132245a4e64696e4d7062327......) and when I try to login it returns ValueError: Invalid salt.
When I test bcrypt.generate_password_hash [without decode] on heroku bash it returns
b'$2b$12$amVQ6f2.d......'
Current Setup:
Both are running Python 3.6.4. Both Heroku and my local version have identical requirements installed. bcrypt==3.1.4 Flask-bcrypt==0.7.1 py-bcrypt==0.4
Documentation:
https://flask-bcrypt.readthedocs.io/en/latest/
In Python 3, you need to use decode(‘utf-8’) on generate_password_hash(), like below:
pw_hash = bcrypt.generate_password_hash(‘hunter2’).decode(‘utf-8’)
Final Thoughts:
Any solutions to get my Mac encoding/decoding correctly? Perhaps because MacOS relies on Python 2.7 it's messing it up? But this shouldn't be the case within my virtualenv.....
I've run echo $LANG and looked at the psql server_encoding on local/heroku and they are both identical for utf8.
So! This is a mind boggling problem for a lot of people. Now that I have found a solution, I'm back to post the results.
Solution Part A: [The most important piece is in Solution Part B, this is a minor fix]. The first thing I realized was that I was using double quotes around my utf-8. I then rechecked the documentation and realized it was a single quote .decode('utf-8'). As soon as I did this, it seemed to fix the problem (at least temporarily). Why that fixes it, I'm uncertain, but that's something to try and a small detail to overlook. After a few days of more pushes, the bug popped back up.
Solution Part B: This is the much larger problem that I learned. After hours of searching I stumbled on a google search that was something along the lines of "Flask-bcrypt py-bcrypt conflict". There were some ambiguous stack overflow questions and github issues that lead me to realize there was likely something conflicting between these packages. So naturally I removed them an reinstalled py-bcrypt, flask-bcrypt, and bcrypt. Same problem. Then I did it again in a different order....new problem....about ffi being missing. So then I uninstalled all of them and ONLY installed flask-bcrypt. Well wouldn't you know...that fixed the problem for Heroku and my local. It turns out that when you install flask-bcrypt it auto installs bcrypt. I left py-bcrypt uninstalled entirely. It seems bcrypt and py-crypt really don't like each other.
Hope that fixes it for you!
(note: I do have this feeling that bcrypt is still accessing py-bcrypt in some way, maybe through headers or the python package itself. Regardless, removing it from my virtual environment did the trick).
(alternative solution: I heard if these packages just really don't play nice, you can use generate_password_hash from something like werkzeug or try installing the cryptography package. I didn't want to go that route though, but worth a shot).
Related
Even after installing dash - getting module import error.
Pycharm does not throw any compilation errors on the line as well.
How could this be resolved?
I tried everything as suggested in comments and stuff known to me but could not resolve this - have done this a thousand times earlier but don't know what went wrong this time.
The only solution the=at worked was to create a new project, copy files over manually and then create a fresh interpreter and VE.
A couple of days ago I cloned a git repository and tried to make a build out of that code with PyBuilder; however, I have not been able to do so.
Every time I run pyb -X -E jenkins-zipfile-release in Bash I get the following error: BUILD FAILED - Error initializing ctypes. The thing is, none of my colleagues have this problem, we don't know why.
The traceback tells me the problem is here: .../pyenv/versions/2.7.14/lib/python2.7/site-packages/oscrypto/_openssl/_libcrypto_ctypes.py
We thought the problem that my python was not correctly compiled with SSL. We even had a different SSL version. I replaced LibreSSL with OpenSSL, but the problem persists.
Another person told me that maybe the oscrypto libraries are conflicting (one from the environment and the other one from the project's lib directory) How can I check that?
I would deeply appreciate if someone could point me in the right direction, I've been trying for two days now.
There was an issue with regards to running oscrypto in a High Sierra. The issue was fixed and it will be a part of the next release.
More info: https://github.com/wbond/oscrypto/issues/22
I have been trying to use the django-visits module, though I seem to not even get this to run cause the minute I follow the instructions for just adding it to my application here:
https://bitbucket.org/jespino/django-visits/src/c3ac83b91969?at=default
It gives me an error when I try to run server:
ERRORS:
visits.Visit.ip_address: (fields.E900) IPAddressField has been removed
except for support in historical migrations.
HINT: Use GenericIPAddressField instead.
Their hint was helpful enough, but I have no idea where pip instaleld my django-visits to where I can change the model code of this module to fix the IPAdressField
Am I approaching solving this error wrong? Should I not be looking for the original code that was installed somewhere on my machine? Do I need to somehow install this from source and not use Pip since I have to change the models.py in this module?
(I am trying to make this work on my OS X machine but ultimately will need to get this to work on CentOS box). Also the database is postgres/postgis
I'm new to Hbase and I would like to comunicate with it throught a python API which works with Thrift. I've followed this tutorial in order to install it properly on my machine, everything seemed to worked fine then I generated a .thrift file with the following command:
wget http://svn.apache.org/viewvc/hbase/trunk/hbase-thrift/src/main/resources/org/apache/hadoop/hbase/thrift/Hbase.thrift\?view\=markup
-O hbase.thrift
Then I tried to generate my client like it's showed here but i get the following error message:
[ERROR:/home/tests/hbase/hbase.thrift:12] (last token was '<')
syntax error
[FAILURE:/home/tests/hbase/hbase.thrift:12] Parser error during include pass.
I tried to lookup on internet what was the cause of this error and found this paper, I tried to lookup in thriftl.ll to see if I could correct the error but I found that the correction was already present in the file.
What can I do more in order to make this work ?
Thank you !
EDIT:
I'm using thrift 0.9.0
Using a fairly recent Thrift version and more importantly the proper URL I was able to generate Python sources without errors.
Please check if your download is actually a Thrift file or if it is a HTML source. The error message sounds very much like that, since HTML pages typically start with an <, and the right Thrift file contains the first < at line 110 (within list<Mutation>), not around line 12.
PS: Why are you using such an old version? 0.9.1 was released a year ago and 0.9.2 is actually in the process of being released.
PPS: Actually, the referenced ticket THRIFT-1274 seems not have much to do with it. But maybe I'm overlooking something.
Recently I tried to install Trac on my Fedora 15, but I got trouble.
I followed steps with this link: http://www.diybl.com/course/6_system/linux/Linuxjs/20100524/204237.html
Yeah, it was wonderful and finally it worked. But after I add a [header_logo] section in trac.ini, it came out this error. And I tried to delete the [header_logo] section, but strangely it wouldn't work. And I don't know why.
I have searched the internet and got this link: http://axcoto.com/blog/article/840.
Yeah, as this link says, it is a permission error. But even after I change all things to the top level of permission, it didn't work either. I must confess that I'm bored. Can anyone help me? Thanks with all my heart.
The [header_logo] section is totally unrelated to the other issue - Trac complaining for not getting a connection to the Trac db backend.
Corresponding settings for that are in section [trac] (with default value):
database = sqlite:db/trac.db
more like user, passwd,... depending on your db type
Two more things to look at:
create a second, fresh Trac environment and compare the trac.ini in it against the one you've possibly damaged (You know the diff command, don't you?)
compare permission settings of your Trac db file /db/trac.db
I recently had this problem too when I had the migrate an old SVN/Trac system to an internally available legacy box and it turned out that SQLite wasn't installed on my system.
I'm on Ubuntu and simply had to do a:
sudo apt-get install sqlite
For me this solved the problem.