mirror of
https://github.com/cypht-org/cypht.git
synced 2026-04-25 04:56:03 +03:00
[GH-ISSUE #273] Error with Api Login, Codeigniter #235
Labels
No labels
2fa
I18N
PGP
Security
Security
account
advanced_search
advanced_search
announcement
api_login
authentication
awaiting feedback
blocker
bug
bug
bug
calendar
config
contacts
core
core
devops
docker
docs
duplicate
dynamic_login
enhancement
epic
feature
feeds
framework
github
github
gmail_contacts
good first issue
help wanted
history
history
imap
imap_folders
inline_message
installation
keyboard_shortcuts
keyboard_shortcuts
ldap_contacts
mobile
need-ssh-access
new module set
nux
pop3
profiles
pull-request
question
refactor
release
research
saved_searches
smtp
strategic
tags
tests
themes
website
wordpress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/cypht#235
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @bet0x on GitHub (May 18, 2018).
Original GitHub issue: https://github.com/cypht-org/cypht/issues/273
Originally assigned to: @jasonmunro on GitHub.
Hello @jasonmunro i did an small integration following your Wiki example, i created a gist with the code:
https://gist.github.com/bet0x/6b17b900dc0782f77bd845d6df3c5329
After testing the variables are printed, no errors, all is okey. i Enabled the module for api and added a key, executed
php ./scripts/config_gen.phpbut still cannot login. There is no errors with my code and Cypht is working properly.@jasonmunro commented on GitHub (May 18, 2018):
I'm out of town for a few days but will check into this when I get back. Thanks for the feedback!
@bet0x commented on GitHub (Jun 18, 2018):
Any news on this @jasonmunro ?
@jasonmunro commented on GitHub (Jun 18, 2018):
@bet0x Looking at your code nothing is jumping out at me as obviously wrong. Just to clarify, the request_login method is returning values for hm_id and hm_session, correct? Sounds like that bit is working but the post form to cypht for the actual login is failing. Just want to make sure I'm understanding the situation :)
@bet0x commented on GitHub (Jun 19, 2018):
Yes, i did a few changes, for example everything is over SSL. The API_KEY is the same on the config, i ran the config gen after that. There is a way to see what process_api_login is getting after the post?
@jasonmunro commented on GitHub (Jun 19, 2018):
You will want to enable Cypht debug mode (https://github.com/jasonmunro/cypht/wiki/Troubleshooting-Login-Issues), which is just using a different document root and index.php file. This will cause Cypht to output a bunch of debug info to the PHP log file, and it allows you to do:
elog($var)
anywhere in the Cypht code. This will add entries to the PHP log regardless of the data type of $var.
The code that handles that HTTP POST is here:
https://cypht.org/docs/code_docs/source-class-Hm_Handler_process_api_login.html#29-55
Hope that helps! When I get some time I will re-test the api login flow to see if something recently broke.
@jasonmunro commented on GitHub (Jun 19, 2018):
Sorry, that link to the code is the module that generates the hm_id and hm_session values, the module just above it is the one that accepts the POST form:
https://cypht.org/docs/code_docs/source-class-Hm_Handler_api_login_step_two.html#10-27
@lysaan commented on GitHub (Jun 20, 2018):
@jasonmunro cypht_login($user, $pass, $url, $lifetime=0) does not generate hm_id_cookie and hm_session_cookie. I don't know whats wrong with it (File cypht/modules/api_login/api.php).
@bet0x I was facing same problem the hack I did was I generated and deleted cookies in my own Login and Logout Controller respectively.
P.S comment out $hm_id_cookie and $hm_session_cookie in cypht_login function, return values in array from that function and generated and deleted cookies in your controllers at your own.
@bet0x commented on GitHub (Jun 20, 2018):
After a while, on developer mode, there is this on my logs:
`==> /var/log/apache2/access-xxx.log <==
xxx - - [20/Jun/2018:15:01:32 +0000] "POST /webmail/?page=process_api_login HTTP/1.1" 303 709 "https://xxx/cypht/index" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36"
==> /var/log/apache2/error-xxx.log <==
[Wed Jun 20 15:01:32.673419 2018] [php7:notice] [pid 2086] [client xxx:10425] Array\n(\n [0] => Including site module set lib.php\n [1] => Using Hm_PHP_Session with Hm_Auth_DB\n [2] => Using file based user configuration\n [3] => Using sapi: apache2handler\n [4] => Request type: HTTP\n [5] => Request path: /webmail/\n [6] => TLS request: 1\n [7] => Mobile request: 0\n [8] => Page ID: home\n [9] => LOGGED IN\n [10] => HTTP header fingerprint check failed\n [11] => Deleting cookie: name: hm_session, lifetime: 1529503292, path: /webmail/, domain: xxx, secure: 1, html_only 1\n [12] => Deleting cookie: name: hm_id, lifetime: 1529503292, path: /webmail/, domain: xxx, secure: 1, html_only 1\n [13] => Deleting cookie: name: hm_reload_folders, lifetime: 1529503292, path: , domain: xxx, secure: 1, html_only \n [14] => Deleting cookie: name: hm_msgs, lifetime: 1529503292, path: /webmail/, domain: xxx, secure: 1, html_only 1\n [15] => TRANSLATION NOT FOUND :Test Webmail:\n [16] => PHP version 7.2.5-0ubuntu0.18.04.1\n [17] => Zend version 3.2.0\n [18] => Peak Memory: 4096\n [19] => PID: 2086\n [20] => Included files: 72\n)\n, referer: https://xxx/cypht/index
==> /var/log/apache2/access-xxx.log <==
xxx - - [20/Jun/2018:15:01:32 +0000] "GET /webmail/?page=home HTTP/1.1" 200 2063 "https://xxx/cypht/index" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36"`
@jasonmunro commented on GitHub (Jun 20, 2018):
@bet0x Thanks for the follow up, the problem is this:
The header fingerprint check is a security layer that simply hashes the values of HTTP request headers that are unlikely to change while you are logged in. It will fail by design when using the API login method since the request headers used by curl when getting the hm_id and hm_session values will differ from the browser when doing the POST form to actually login. The api login module is supposed to disable the fingerprint check for the api login flow, then re-enable it once the normal login is achieved, so there is a bug in the module around this logic. I will try to reproduce the issue and confirm.
In the meantime you can work around that issue by setting the "disable_fingerprint" setting in your hm3.ini file to true, and rerunning the config gen script. Let me know if that works for you!
@lysaan Thanks for the feedback. bet0x is actually using the alternate api login flow that uses HTTP requests to first start a session, then a HTTP POST form to finish the process by setting the cookies etc. the cypht_login() method is part of the "functional" style api login flow (which only works if your integrating with other PHP apps). My guess is that in your case the cypht_login function that attempts to set cookies is failing because either the properties of the cookie being set are incorrectly calculated so the browser ignores them, or something about the site configuration is causing them to fail.
With that said, I would be happy to add your work around to the code. We could add an optional argument to cyph_login that would return the id values instead of attempting to set the cookies from within the function.
@bet0x commented on GitHub (Jun 20, 2018):
@jasonmunro Tried this other method:
https://gist.github.com/bet0x/c529ee9c24c0dda0910f675e4fdf8330
Still, not working, also i disabled disable_fingerprint
@jasonmunro commented on GitHub (Jun 20, 2018):
disable_fingerprint should be enabled - set to true, not disabled. Can you show me the log entries with this change in place after a failed login attempt?
@bet0x commented on GitHub (Jun 20, 2018):
oh, value is true for disable_fingerprint , seems to log in because i get on my URL: https://xxx/webmail/?page=home that's the redirect after successful log in right?
@bet0x commented on GitHub (Jun 20, 2018):
@bet0x commented on GitHub (Jun 20, 2018):
What [11] => LOGGED IN means? (i know what it means, but for the software...) Because to me is like everything's okay, i LOGGED IN but i still see the login and if i do refresh i keep on the same page.
@jasonmunro commented on GitHub (Jun 20, 2018):
I'm not seeing any errors in what you posted, and the LOGGED IN line indicates that the request was considered valid for a logged in user. Are you seeing the cypht application home page or a login form still?
@bet0x commented on GitHub (Jun 20, 2018):
Login still after that. Means that,
Hm_Handler_api_login_step_twois executing okay, andHm_Dispatch::page_redirect('?page=home');too but doesn't actually show me the webmail interface@jasonmunro commented on GitHub (Jun 20, 2018):
This is really weird. Everything looks like it should be working! The only thing I can think of to try next is to switch from PHP sessions to DB sessions. Cypht does some unique things with sessions, so there may be a conflict there.
To enable DB sessions you need to change session_type to DB in the hm3.ini file (rerun the config gen of course), and create the hm_user_session table in the database. The DB session support in Cypht is completely independent from PHP session internals - so if this works or does not work, it will be a solid clue pointing us to what is going wrong.
@bet0x commented on GitHub (Jun 20, 2018):
I swapped to DB after config and everything, log here:
==> /var/log/apache2/access-xxx.log <==
xxx - - [20/Jun/2018:20:03:18 +0000] "POST /webmail/ HTTP/1.1" 200 4329 "-" "-"
As you can see, still doesn't show me webmail lol
What this means:
[10] => LOGGED IN\n [11] => IDLETIMER: timer exceeded, logged out\n@bet0x commented on GitHub (Jun 20, 2018):
Well i FOUND IT FINALLY! I disabled the idle_timer module and not it works! Geez, this was a long debug. @lysaan Do what i did, disable modules[]=idle_timer and try again (run config gen ofc).
@jasonmunro commented on GitHub (Jun 20, 2018):
OMG I can't believe I forgot about that! Honestly I think I need to just remove the module as it has caused login issues before. Thanks for hanging in there to figure this out!
@bet0x commented on GitHub (Jun 20, 2018):
@jasonmunro Do not worry, has been fun, now i know a little more about the internals.
@jasonmunro commented on GitHub (Jun 20, 2018):
Just added this to the api login wiki page:
Note that the idle_timer module set currently does not play nice with API logins, be sure to disable that module set in your hm3.ini!
Again, thanks for your patience on this! I swear I will get back to your other requests (menu item, contacts module), just been super busy at work but things are starting to settle down a bit.
@bet0x commented on GitHub (Jun 20, 2018):
@jasonmunro Great, have a nice day!