vb.org Archive

vb.org Archive (https://vborg.vbsupport.ru/index.php)
-   vB3 Programming Discussions (https://vborg.vbsupport.ru/forumdisplay.php?f=15)
-   -   Override login on external page (https://vborg.vbsupport.ru/showthread.php?t=275045)

stupha 12-04-2011 11:15 PM

Override login on external page
 
vB 3.8.4
I'm using the usual include globals.php and $vbulletin->userinfo['userid'] to have an external page only visible to logged-in vB users.

something in globals.php - or its includes - is not letting me do the checking for a logged-in user (see code below). Instead, it presents a login form under the page URL, not the login URL.

if my locked-down page is:
http://mysite.com/you-cant-see-this/

When I submit the login form there, of course, I get an error because it submits to:
http://mysite.com/you-cant-see-this/login.php?do=login

The code I'm using goes like this...

PHP Code:

chdir('/server/path/to/forums/');
require_once(
'global.php');

if (!
$vbulletin->userinfo['userid']) {

.. 
etc... 

But when a user is not logged in, the script never reaches the IF because something in globals.php just goes ahead and builds the standard login page.

Is there a way to absolutely force logins only on the standard vB forum login URL?
Or is there something else I can do here to be able to check the logged-in status of the user correctly?

kh99 12-05-2011 01:10 AM

It could be a cookie path thing - under "Help Cookies and HTTP Header Options" there's a Cookie Path option, and if it's not set to "/", and your external page is in a different directory than the rest of the vb file, then users won't appear to be logged in.

stupha 12-05-2011 07:49 AM

Good suggestion, thanks. I checked and it is set to /
I think I'll dig more into the cookie settings, that might be a good direction to explore, I think.

The forum is in a subdirectory /forums, and the page checking for the login is effectively in another subdirectory of the root. The script does see a logged-in user just fine, though, just has this odd (to me) behaviour when the user is not logged-in.

kh99 12-05-2011 01:57 PM

Hmm...if it works for logged in users it probably isn't a cookie issue. I was looking through the code to see why it would print a login page, and it looks like if you pass a forum or thread id to the script (or use parameters 'f' or 't' for something), it could decide that the user has no permission. Is there any error message being displayed before it goes to the login page?

You might try temporarily creating a plugin using hook header_redirect with code somethign like this:

Code:

debug_print_backtrace();
die("<BR/>Exiting from header_redirect plugin.");


and that let you figure out where the redirect is being called from.

stupha 12-05-2011 02:19 PM

There's no redirect, however. The URL remains the same, but the default login form is rendered right there. I can see some logic in that behaviour because the login form then knows the requested page and can redirect back there after login.

As a temporary measure, I have edited the login form template to hard-code the full URL of the forum's login script - so now the login form posts to the correct URL, and redirects back to the original requested page after. That at least gets things working with most of the behaviour they want.

I'm still curious as to how to use global.php and $vbulletin->userinfo['userid'] to check logged-in status as it seems to be commonly discussed as a means of sniffing user logged-in status outside the forum.

I have to show a login/logout pop on non forum pages, so when I include global.php to sniff the logged-in status, I get the same problem of the login form being rendered.

I'll mess around with plugins and debug, it's bound to give me some insight, though I don't see any that immediately suggest they relate to rendering of a login form.
I haven't had to play with the hooks until now, so that should be fun ;)

Thank you for the suggestions.

kh99 12-05-2011 02:26 PM

Oh, I guess I saw where you mentioned login.php in the first post and thought it was redirecting there, but now I see you said that it goes there if you try to log in.

If you figured out which template it is you should be able to figure out where it's being called from (if you're still interested - sounds like you found a fix).


All times are GMT. The time now is 10:01 AM.

Powered by vBulletin® Version 3.8.12 by vBS
Copyright ©2000 - 2025, vBulletin Solutions Inc.

X vBulletin 3.8.12 by vBS Debug Information
  • Page Generation 0.01150 seconds
  • Memory Usage 1,726KB
  • Queries Executed 10 (?)
More Information
Template Usage:
  • (1)ad_footer_end
  • (1)ad_footer_start
  • (1)ad_header_end
  • (1)ad_header_logo
  • (1)ad_navbar_below
  • (1)bbcode_code_printable
  • (1)bbcode_php_printable
  • (1)footer
  • (1)gobutton
  • (1)header
  • (1)headinclude
  • (6)option
  • (1)post_thanks_navbar_search
  • (1)printthread
  • (6)printthreadbit
  • (1)spacer_close
  • (1)spacer_open 

Phrase Groups Available:
  • global
  • postbit
  • showthread
Included Files:
  • ./printthread.php
  • ./global.php
  • ./includes/init.php
  • ./includes/class_core.php
  • ./includes/config.php
  • ./includes/functions.php
  • ./includes/class_hook.php
  • ./includes/modsystem_functions.php
  • ./includes/class_bbcode_alt.php
  • ./includes/class_bbcode.php
  • ./includes/functions_bigthree.php 

Hooks Called:
  • init_startup
  • init_startup_session_setup_start
  • init_startup_session_setup_complete
  • cache_permissions
  • fetch_threadinfo_query
  • fetch_threadinfo
  • fetch_foruminfo
  • style_fetch
  • cache_templates
  • global_start
  • parse_templates
  • global_setup_complete
  • printthread_start
  • bbcode_fetch_tags
  • bbcode_create
  • bbcode_parse_start
  • bbcode_parse_complete_precache
  • bbcode_parse_complete
  • printthread_post
  • printthread_complete