Ad blocker detected: Our website is made possible by displaying online advertisements to our visitors. Please consider supporting us by disabling your ad blocker on our website.
In include/auth.php, change the current line 43 (indicated with '<') to my version (indicated with '>')
In auth_login.php, add, after the current line 26, 'my' line 27-36, indicated with '>'.
And add, after the original line 74 (which is now 84, due to the above change which inserted 11 lines), lines 85-89.
I admit that the format of this isn't very clear...
I should have posted a 'normal' diff which can be applied using the patch-program....
Passing passwords on the URL will not be considered.
[size=117][i][b]Tony Roman[/b][/i][/size]
[size=84][i]Experience is what causes a person to make new mistakes instead of old ones.[/i][/size]
[size=84][i]There are only 3 way to complete a project: Good, Fast or Cheap, pick two.[/i][/size]
[size=84][i]With age comes wisdom, what you choose to do with it determines whether or not you are wise.[/i][/size]
rony wrote:Passing passwords on the URL will not be considered.
From a security perspective, this is absolutely on the money.
However, from a useability perspective - what would you recommend when a user is already authenticated into a Portal solution (like SharePoint) and needs to pull up a dashboard with a few graphs?
I have installed this plugin but something doesn't work.
Authentication perfectly works but the browser returns me the default graph screen.
Nevertheless the login options in user management section is set to : "show the page that user pointed their browser to"
rony wrote:Passing passwords on the URL will not be considered.
From a security perspective, this is absolutely on the money.
However, from a useability perspective - what would you recommend when a user is already authenticated into a Portal solution (like SharePoint) and needs to pull up a dashboard with a few graphs?
Chris
Use one-time keys. When the user authenticates to the portal, generate a key for them. Extend and update the user table in cacti to support that key. Write the generated key into the cacti user table for the appropriate user. Call Cacti with the key on the URL, and expire the key when they log out (or after a certain amount of time).
Alternately, use the export mechanism of Cacti and put the graphs behind the portal solution itself.
We would like to use one-time keys to authenticate as suggested. We've made changes to the cacti database for our portal to insert the keys, but I'm not sure how best to modify cacti to use these keys.
The last post suggested that this may be supported officially, or at the very least someone else has done it.
If anyone can point me at a how to or other documentation I would really appreciate it.
Thanks for your reply, but I am afraid I'm not sure what you are driving at. if you wouldn't mind spelling it out a bit more I would appreciate it.
We've got an existing portal which allows customers to view services that they have with us amongst other things. They have to authenticate to get into our portal.
We also have Cacti running on linux. We have automated the setup of new cacti accounts for every new service and we email the customers cacti details automatically once the service is setup but we want to avoid them having to remember two sets of details. We would like them to be able to log in to our portal view their services and then be able to follow a link from any service to the cacti graph for that service without having to login again.
I'm just trying to avoid reinventing the wheel here. Our portal is quite capable of inserting a one-off key into the sql database on the cacti machine, then removing it after use, but I don't want to go hacking around in cacti if there's already an accepted way of doing this. I'm struggling to find any documentation.
I know that SSO = Single Sign On, but I've not heard of Web Basic. I'm sure I'm missing something really obvious.