Closed robotman321 closed 5 years ago
thomnico
commented
5 years ago Hello,
Thanks for the very well documented bug report, greatly appreciated.
Post-login banner are only meaningfull to humans, program using API won't read it.
We do not plan to support this behavior, will happily review pull request with associated tests.
We recommend to have an API login with banner or even better a API token (which this lib supports). Documented on http://fndn.fortinet.net
Hope this helps,
robotman321
commented
5 years ago Thanks, I don't like the post-login-banner option myself, equally frustrating is that somehow this setting has a bearing over an API that will only be used by programs. However the clientele i'm working with have brand specific policies that require pre- and post-login banners.
I'll just have to unset this value at runtime using netmiko and then re-set it after the application succeeds, I was just hoping there had been some development from the api point of view that would have mitigated the unintended results of setting that value. Oh well. Thanks though.
codyroche
commented
5 years ago Hey, if you need to do this and are OK with writing your own API connection handler it shouldn't be too hard. Just follow-up the 200 you get from '/logindisclaimer?viewOnly&redir=%2Fng%2F' with a POST to '/logindisclaimer' and content of 'confirm=1&redir=%2Fng%2F'.
You can see the strings in the JavaScript on the authentication page and the method formatting in a Fiddler trace of the banner interactions.
It's not as nice as the API doing it for you, but it'll work if you want this to work without modifying the configuration every time you run your code.
robotman321
commented
5 years ago @codyroche that's actually perfect, I was going to investigate that today after putting out fires but you've done all of my work, thank you! Now i won't need to use a pre-release version of netmiko (hah!).
I really appreciate it, hopefully this helps someone else down the line (i can't be the only one, heh)
codyroche
commented
5 years ago Agreed, I just started with Fortinet APIs last week, but wanted to figure it out for the same reasons you mentioned. I can't always use an API key so it's a fun trick.
On Wed, Aug 7, 2019, 12:27 Brad Riemann notifications@github.com wrote:
@codyroche https://github.com/codyroche that's actually perfect, I was going to investigate that today after putting out fires but you've done all of my work, thank you! Now i won't need to use a pre-release version of netmiko (hah!).
I really appreciate it, hopefully this helps someone else down the line (i can't be the only one, heh)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/fortinet-solutions-cse/fortiosapi/issues/50?email_source=notifications&email_token=ACWAA2THOQJ5MGWEKHDANT3QDMAZTA5CNFSM4IJZKODKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3ZEJYA#issuecomment-519193824, or mute the thread https://github.com/notifications/unsubscribe-auth/ACWAA2XKRTDUJEPPER5YZSTQDMAZTANCNFSM4IJZKODA .
thomnico
commented
5 years ago @codyroche will accept a pull request on this project that implement what you describe (just saying)
I need to try but I assume you won't have the issue using the api-key user with keeping the banners in place for humans. It is not really a different user but a supported apit-token supported in the lib.
Hope this helps,
codyroche
commented
5 years ago @thomnico not sure when I'd have time, but I'd be interested.
thomnico
commented
5 years ago To both I am very curious to understand why using api-user is not an option ? Check https://docs2.fortinet.com/document/fortigate/6.2.1/cli-reference/16620/system-api-user
Find a login example here : https://github.com/fortinet-solutions-cse/fortiosapi-examples/blob/master/apilogin.py
codyroche
commented
5 years ago Hey @thomnico, It's not that I wouldn't prefer API authentication, but rather will the customer allow it. Since it's a static key option right now some environments won't like it. TACACS, LDAP, or RADIUS is generally preferred in those cases.
Using a client certificate is an option with the API that helps manage the risk, but doesn't help me if I'm just trying to do some rapid data collection. Same with ensuring that various API keys have limited access to the platforms, it just minimizes risk and doesn't address the locally configured static key completely.
It'd be nice if the Fortigate appliances would support OAuth, since it addresses a lot of the security complaints you get with static API keys. I don't see that happening any time soon though, right?
thomnico
commented
5 years ago Thanks for your perspective. Fortigate supports LDAP and RADIUS sso already.
Creating an API user with the least privileges is probably more important (and complex) than the method of authentication.
The goal of this GitHub it to provide easy programmable access to the API, Fortigate feature requests should be discussed with your Fortinet Rep.
Hope this helps,
I tried engaging support, but was told the Technical Team doesn't support the API even though its clear the issue stems from the use of the post-login-banner option being set. I am opening this issue up in hopes for clarity around the 401 response that i am getting using the fortiosapi library.
I also asked about this being a potential bug but got no response.
Thank you.
stdout from script:
Test script:
output in testfortiosapi.log: (with post-login-banner set in config)
output in testfortiosapi.log: (WITHOUT post-login-banner set in config)