Closed diamant-x closed 2 years ago
The (encrypted) access token is cached in a cookie, and could also be present in the FIREFLY_III_ACCESS_TOKEN
environment variable. If the two data importers share the same (sub)domain, the information from one FIDI instance can leak to the other one.
Can't find any specific mention about the connection to firefly3 from fidi, all the logs are related to the (succesful) connection to nordigen.
Look for stuff like this:
[2022-04-13 14:42:17] local.DEBUG: Now at App\Http\Controllers\TokenController::index
[2022-04-13 14:42:17] local.DEBUG: No access token in hasAccessToken(), will return config variable.
[2022-04-13 14:42:17] local.DEBUG: No client id in hasClientId(), will return config variable.
[2022-04-13 14:42:17] local.DEBUG: No base url in getBaseUrl(), will return config variable.
[2022-04-13 14:42:17] local.DEBUG: No vanity url in getVanityUrl(), will return config variable.
[2022-04-13 14:42:17] local.INFO: The following configuration information was found:
[2022-04-13 14:42:17] local.INFO: Personal Access Token: "" (limited to 25 chars if present)
[2022-04-13 14:42:17] local.INFO: Client ID : "0"
[2022-04-13 14:42:17] local.INFO: Base URL : "http://firefly.jc.home"
[2022-04-13 14:42:17] local.INFO: Vanity URL : "http://firefly.jc.home"
[2022-04-13 14:42:33] local.DEBUG: Now at App\Http\Controllers\TokenController::submitClientId
[2022-04-13 14:42:33] local.DEBUG: Submitted data: {"client_id":"4","base_url":"https://firefly.jc.home/"}
[2022-04-13 14:42:33] local.DEBUG: Base URL is "http://firefly.jc.home"
[2022-04-13 14:42:33] local.DEBUG: Vanity URL is now "http://firefly.jc.home"
[2022-04-13 14:42:33] local.DEBUG: Base URL is now "https://firefly.jc.home/"
[2022-04-13 14:42:33] local.DEBUG: Now in App\Http\Controllers\TokenController::redirectForPermission(request, "https://firefly.jc.home", "http://firefly.jc.home", 4)
[2022-04-13 14:42:33] local.DEBUG: Query parameters are {"client_id":4,"redirect_uri":"https://firefly-data.jc.home/callback","response_type":"code","scope":"","state":"UPxnrSwGEp4lAOspwLpRcw1E2oJY7FyAP2QNITky","code_challenge":"d9kcEJhV6k_vwSOYorDmfrvlH5kexzmaB_-nuVtOAR4","code_challenge_method":"S256"}
[2022-04-13 14:42:33] local.DEBUG: Now redirecting to "http://firefly.jc.home/oauth/authorize?" (params omitted)
[2022-04-13 14:42:34] local.DEBUG: Now at App\Http\Controllers\TokenController::callback
[2022-04-13 14:42:34] local.DEBUG: State is valid!
[2022-04-13 14:42:34] local.DEBUG: Params for access token {"form_params":{"grant_type":"authorization_code","client_id":4,"redirect_uri":"https://firefly-data.jc.home/callback","code_verifier":"1m...e"}}
[2022-04-13 14:42:34] local.DEBUG: Will contact "https://firefly.jc.home/oauth/token" for a token.
[2022-04-13 14:42:36] local.DEBUG: Response {"token_type":"Bearer","expires_in":1209598,"access_token":"eyJ0eXAi...b902169c65e79078c0869"}
[2022-04-13 14:42:36] local.DEBUG: Return redirect with cookies to "https://firefly-data.jc.home"
The (encrypted) access token is cached in a cookie, and could also be present in the FIREFLY_III_ACCESS_TOKEN environment variable. If the two data importers share the same (sub)domain, the information from one FIDI instance can leak to the other one.
Both FiDis are deployed in the same docker host, so they share the same subdomain, one is working on port 3474 and the other in port 3475. I'm not sure to understand how that would be an issue?
This is the log i'm getting. I do see that the beginning of the personal access token is identical for both users, not sure if that might clash?
[2022-04-13 14:58:01] production.DEBUG: Now at App\Http\Controllers\IndexController::reset
[2022-04-13 14:58:01] production.INFO: The following configuration information was found:
[2022-04-13 14:58:01] production.INFO: Personal Access Token: "<redacted-token>" (limited to 25 chars if present)
[2022-04-13 14:58:01] production.INFO: Client ID : "0"
[2022-04-13 14:58:01] production.INFO: Base URL : "http://mydomain:3473"
[2022-04-13 14:58:01] production.INFO: Vanity URL : "http://mydomain:3473"
[2022-04-13 14:58:01] production.DEBUG: Found personal access token + URL "http://mydomain:3473" in config, set cookie and return to index.
192.168.10.26 - - [13/Apr/2022:14:58:01 +0200] "GET /token HTTP/1.1" 302 4651 "http://mydomain:3475/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.75 Safari/537.36 Edg/100.0.1185.39"
[2022-04-13 14:58:01] production.DEBUG: Now in App\Http\Controllers\IndexController::index
[2022-04-13 14:58:01] production.DEBUG: App\Services\Shared\Authentication\SecretManager::hasValidSecrets
I see that my logs don't include the 'Response' from the FF3 like yours. any way to force that to appear?
Support guidelines
I've found a bug and checked that ...
Description
I have one Firefly3 setup with two different users, i want each of them to have an automatic fidi to import their independent transactions.
I have setup already Fidi for one of the users, with its own Personal Access Token. I have setup Fidi with a unique set of Nordigen app keys. Nordigen import works fine and when creating the config, the dropdown of firefly accounts matches those available for user1.
I have deployed a new FiDi container, with a separate config folder and instance. I have setup FiDi with a new Personal Access Token under user2. The tokens are clearly different between those of user1 and user2. I have setup FiDi2 with new Nordigen app keys from the same organization, so different app keys from user1. When creating a new nordigen config flow in the new container for user2, the lsit of available accounts are the same as those for user1, and those of user2 are not available at all. user2 uses the same bank and bankaccount user2 is a FF3 admin account.
Thanks!
Expected behaviour
FiDi from user1 sees its own firefly accounts only FiDi from user2 sees its own firefly accounts only.
Debug information
Can't find any specific mention about the connection to firefly3 from fidi, all the logs are related to the (succesful) connection to nordigen.
Steps to reproduce
Additional info
No response