Login from a login form on another Website

Post general support questions here that do not specifically fall into the Linux or Windows categories.

Moderators: Developers, Moderators

Post Reply
cb250
Posts: 8
Joined: Mon Sep 19, 2005 2:52 pm

Login from a login form on another Website

Post by cb250 »

We are trying to configure our website to allow a customer to login to cacti via a form. In other words, a customer would go to our Website, select Cacti from the list of tools, type in their username and password and login. Currently, the login request is not being granted, but instead directs the user to the standard login screen. We have other tools that work using this method.

Does Cacti require that the login info come from index.php? Any ideas as to how I can make this work? We use the following form:

<form name='login_frm' action='' method='post' onSubmit='return validate(this);'>
<tr>
<td><b>Username:</b></td>
<td><input type='text' name='usr' maxlength=45 /></td>
</tr>
<tr>
<td><b>Password:</b></td>
<td><input type='password' name='pwd' maxlength=15 /></td>
</tr>
<tr>
<td><b>Site:</b></td>
<td>
<select name='sites'>
<option value='http://cacti.domain.com/cacti/index.php ... th</option>
</select>
</td>
</tr>
<tr>
<td>&nbsp;</td>
<td>
<input type='submit' name='submit' value=' Login ' />
</td>
</tr>

</form>
</table>



Thanks,

CDB
User avatar
rony
Developer/Forum Admin
Posts: 6022
Joined: Mon Nov 17, 2003 6:35 pm
Location: Michigan, USA
Contact:

Post by rony »

Ok I know this code like the back of my hand.... Well, better, as I don't look at the back of my hand as much.. :)

1. Form method must be POST
2. Username is expected to be passed as "login_username"
3. Password is expected to be passed as "login_password"
4. You will need a hidden variable called "action" with a value of "Login"

How you will do this from your site, well that's up to you. You might have to do some strange things to get it to post right, like have some hidden elements that you copy the values to before you submit the form with javascript. This way you can retain the username/password field names you need for other applications and it will work with cacti.

Also, by not modifing the cacti code, you are in a better position to install upgrades in the future without having to reapply these changes.

Any questions, let me know.
[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]
User avatar
SJFriedl
Posts: 8
Joined: Sun Sep 04, 2005 11:45 am
Location: Tustin, California USA
Contact:

Post by SJFriedl »

Hmmm, this is helpful... partly.

We have a monitoring page outside of Cacti upon which we placed a {form} which provides this functionality:

(form action="http://myurl.example.com/cacti/" method="POST")
(input type=hidden name="login_username" value="customername")
(input type=hidden name="login_password" value="hispassword")
(input type=hidden name="action" value="login")
(input type=submit value="Go To Cacti")
(/form)

In a fresh browser, this works great. The form is submitted, and Cacti replies with a 302 ("Found") with the redirect to the proper view_graph.php page, and it sets the PHPSESSID cookie. The browser takes this and hits the proper page. All is well.

But if in the same browser session we got back to the first page and click the same form link again, Cacti responds with an access denied error. Sniffing the TCP, I see that the only difference is that the HTTP request includes the PHPSESSID cookie.

That particular session file (/tmp/sess_{longsessionname}) is there, though I haven't dug into the contents.

Using the printf-debugging method, I see that the test

select user_auth_realm.realm_id from user_auth_realm ...

is failing. After a "working" connection, I don't see that user_auth_realm contains a valid {realm,userid} entry, so either it's not being created, or it's getting deleted.

At this point I am way beyond my experience with the GUI - I'm a poller guy - so am appealing to the forum for help.

Any ideas? This is really causing me difficulties.

Steve
User avatar
rony
Developer/Forum Admin
Posts: 6022
Joined: Mon Nov 17, 2003 6:35 pm
Location: Michigan, USA
Contact:

Post by rony »

I can see that happening, and I didn't think it all they way through.

So, your answer, if this is for customers, is to not set the post to the "<server>/cacti/", but to set it to "<server>/cacti/graph_view.php". This should resolve the issue you are having. And should get the customer to the correct URL everytime.
[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]
User avatar
SJFriedl
Posts: 8
Joined: Sun Sep 04, 2005 11:45 am
Location: Tustin, California USA
Contact:

Post by SJFriedl »

Well this is a segueway into the other problem, perhaps related: when I post to graph_view.php as suggested, it always gives a blank page. If I do the first click from the other page to cacti, the blank page doesn't appear to be logged in as anybody, and if I manually login to get a session in the same browser, then it shows me a blank page with "Logged in as {customer}" in the upper right.

I guess it's back to printf debugging for me :-)
User avatar
rony
Developer/Forum Admin
Posts: 6022
Joined: Mon Nov 17, 2003 6:35 pm
Location: Michigan, USA
Contact:

Post by rony »

Um...

I take that back, because if Guest access is enabled and there is no session, sending it to graph_veiw.php will not work.

Let me ponder, I might have a solution for this issue.
[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]
User avatar
SJFriedl
Posts: 8
Joined: Sun Sep 04, 2005 11:45 am
Location: Tustin, California USA
Contact:

Post by SJFriedl »

Well we don't want guest access at all: deleting the name of the guest account in Settings -> Authentication seems to have fixed this.

Thanks!
User avatar
rony
Developer/Forum Admin
Posts: 6022
Joined: Mon Nov 17, 2003 6:35 pm
Location: Michigan, USA
Contact:

Post by rony »

Ok, so sending it to graph_view.php with guest access disabled works? And that is what you wanted?

Otherwise, I was going to write a simple gateway login script.
[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]
Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests