sjswarts the sleep statement needs to go on the pages that are redirected to after login (open.php tickets.php view.php). I did also include it on both index.php and login.php in the beginning but I don't think it needs to be there. I put the sleep right after the opening comments of the file, before any of the required files are declared.
In my case the only thing I can come up with is that my new server has more resources and is running faster/more efficient than the old server and is responding back faster than the code is expecting. This is why I was getting the login page again. Once I added the sleep statements to all pages where authentication redirects to then it was working correctly.
@"KevinTheJedi" thank you for the detailed response. Just curious (to try to learn a bit better) why does it work this way with users but agents are different? Also, when you get to the point where you are working on this, I'd be happy to help out in any way you might need.
Cheers!
For some reason the Oauth2 option for Google is allowing any Google account to login to the system and is not restricting to just our users. I have user auto creation turned off but this appears to be bypassing that and auto creating the user anyway.
One other thing to add...
This whole thing got me to thinking about why this is happening on our new system and never happened on the old one. The old version was v1.12.x and we never had this problem. Yet when I search on it, I find others that have reported it all the way back to v1.9.x. So what is different between the old and new systems. Both systems are VM running in the same cluster so the physical hardware is the same. The old VM only had one processor and 1Gb RAM assigned to it. The new VM has two processors and 4Gb RAM assigned to it. There is a very noticeable performance difference in page loads and interacting with the server in general.
I believe what's happening is that the server is processing page loads so fast that it is over running the session id stuff. Especially since I know that authentication is working correctly and it is correctly redirecting to the next page after login, but since the session id cookie stuff isn't getting there before the page loads, the PHP assumes you are not logged in and therefore is displaying the login content again.
Hopefully this help for future development in getting everything to process in order and consistently display correctly.
@KevinTheJedi if you want to DM me I'm happy to help out with this in any way I can.
Cheers!!
Please see the reply I just posted over here...
https://forum.osticket.com/d/105809-user-login-returns-to-the-login-page/5
I got to thinking about this and I didn't see where any of that would affect the problem. Since the authentication is working it is just the code not handling the session correctly. I ended up running across another thread (https://forum.osticket.com/d/95841-user-login-issue/29) and the suggestion here has almost totally solved the problem
Add this line to the top of the index.php and tickets.php files, before any other php code is processed.
sleep(2);
For me I added it right under the comments at the top but before the include statements. If you are not using OAUTH2 then you only need to add it to the tickets.php file. Since OAUTH2 redirects to the index.php file, it has to be there too for that to work.
I was thinking the exact same thing.
I created a new db and a new folder and extracted the source into the new folder. Went through the setup just fine. Under Settings->Users I checked the Registration Required and set the Registration Method to Private. I added the http passthru and ldap plugins and configured them appropriately. Then added a user. When I registered the user from the admin panel, I choose Any Available Backend, set a password, and checked the user cannot change password box. I added another user but the only difference was setting auth to just local.
When I try to login with either user I'm getting the exact same problem. Authentication appears to be good (no red bar saying access denied), the url is tickets.php but the content is the login page.
I know that this has been an issue in the past but I'm unable to find a solution. This is a fairly big deal as it's affecting my user's ability to login to the system.
Hey I'm hitting this same exact thing as well. It's preventing my users from logging in and causing much frustration. What info can I get for you that might help track this down?
I did find where that is being defined. I removed my previous edits made changes appropriate to where the static function is built.
Here is what I have done. I added a variable to the include/staff/ticket-view.inc.php for $allowedTags and then added this variable to the places where Format::striptags is called. I then added the strip_tags function inside the custom static function. This would allow the flexibility of defining the $allowedTags per item, per page. Snippets are below
include/staff/ticket-view.inc.php
$allowedTags = '<p>,<br>';
$v = $html ? Format::striptags($a->display(), $allowedTags) : $a->display();
$clean = (Format::striptags($v, $allowedTags))
? ($html ? Format::striptags($v, $allowedTags) : $v)
: '—' . __('Empty') . '—';include/class.format.php
static function striptags($var, $excludedTags=null, $decode=true) {
if(is_array($var))
return array_map(array('Format','striptags'), $var, array_fill(0, count($var), $decode));
return strip_tags($decode?Format::htmldecode($var):$var, $excludedTags);
}Thank you for all that help. Given I'm on a dev server right now I was able to test out and idea that seems to be working and wanted to let you know what I did.
In the file include/staff/ticket-view.inc.php I found where the Laravel function Format::striptags() is being used to strip out all the HTML. Since this function does not have any built-in control options I switched over to using the PHP funtion strip_tags(). Here is the snippet of what I did that is working for me.
foreach ($displayed as $a) {
$id = $a->getLocal('id');
$label = $a->getLocal('label');
$field = $a->getField();
$config = $field->getConfiguration();
$allowedTags = '<p>,<br>';
$html = isset($config['html']) ? $config['html'] : false;
/* $v = $html ? Format::striptags($a->display()) : $a->display(); */
$v = $html ? strip_tags($a->display(), $allowedTags) : $a->display();
$class = (Format::striptags($v)) ? '' : 'class="faded"';
$clean = (strip_tags($v, $allowedTags))
? ($html ? strip_tags($v, $allowedTags) : $v)
: '—' . __('Empty') . '—';
/* $clean = (Format::striptags($v))
? ($html ? Format::striptags($v) : $v)
: '—' . __('Empty') . '—'; */OK, thank you. Couple more thoughts and questions about this.
When did this get changed? From your stand point, would there be any issues with grabbing the code from the 1.12.1 system and using it in the 1.18.1? I mean just the part for displaying this with HTML.
I'm also a bit baffled as to why we have a wysiwyg type box on the user side for them to type in all kinds of fancy HTML kinda stuff and then completely strip it out when the agent views the ticket. Just trying to understand the bigger picture as to why this change was made.
BTW, huge thank you for all your time in the forum here and all your work on this!
That is actually a huge problem for us. Seems like turning off/on the display of HTML should be up to us. Do you have any recommendations for how to fix this? I cannot go live with the upgrade until that is fixed (it's that big of an issue).
Sure no problem.
Here is a screenshot from the 1.12.2 system
Here is a screenshot from the 1.18.1 system (/scp/tickets.php?id=24766)
Here is a screenshot from the edit ticket page on the 1.18.1 system (/scp/tickets.php?id=24766&a=edit)
I did get everything working. Turned out I had a typo in how I added a comment to a php file and that was breaking everything 
Still have the issue of the _user_account table not having the backend column updated by the update script.
Found one more thing. When viewing a ticket on the agent side that was brought over with the db import the 'Issue Description' field seems to be stipping off the "<br />" tags that are saved in the db.
Here is what the value is in the db
Hi Dave, <br />Please replicate the following tables from dataLink.<br /><br />Server: srv90037<br />Database: lccIRDataLinkDataWarehouse<br /><br />WAREHOUSE_FINAID.FA_AWARD<br />WAREHOUSE_FINAID.FA_AWARD_SNAPSHOT<br />WAREHOUSE_FINAID.FA_STUDENT<br />WAREHOUSE_FINAID.FA_STUDENT_AWARD<br />WAREHOUSE_FINAID.FA_STUDENT_AWARD_SNAPSHOT<br />WAREHOUSE_FINAID.FA_STUDENT_AWD_CANCELED<br />WAREHOUSE_FINAID.FA_STUDENT_NEED<br /><br /><br />I just created a target file using the lccFileRowsTurnOnOff tool. The tables that need to be updated were all found in the tool's checkboxes.<br /><br />Thanks! <br />
And here is how it's being displayed in the browser
Hi Dave, Please replicate the following tables from dataLink.Server: srv90037Database: lccIRDataLinkDataWarehouseWAREHOUSE_FINAID.FA_AWARDWAREHOUSE_FINAID.FA_AWARD_SNAPSHOTWAREHOUSE_FINAID.FA_STUDENTWAREHOUSE_FINAID.FA_STUDENT_AWARDWAREHOUSE_FINAID.FA_STUDENT_AWARD_SNAPSHOTWAREHOUSE_FINAID.FA_STUDENT_AWD_CANCELEDWAREHOUSE_FINAID.FA_STUDENT_NEEDI just created a target file using the lccFileRowsTurnOnOff tool. The tables that need to be updated were all found in the tool's checkboxes.Thanks!
Interestingly when I click to edit the ticket (as an agent), then everything displays correctly.
Okey dokey, looks like the image issue was self inflicted. I reverted all my php changes and now it's working correctly. I'll have to go through my code and see what/where it breaking.
Any thoughts on why the _user_account table didn't update the backend correctly with the update?
I dropped the db and recreated it. Then imported the old db. Everything looks good so far.
Went to run the upgrade script and it is asking me to login (just same as last time). When I enter the local user credentials, it sits and spins. A page refresh just returns to the login. I re-enter the credentials and it spins again. I go to the address bar and remove the login.php so it is just tld/scp and then it loads the upgrade page.
Good news it appears ldap is working for staff, but bad news it's not working for users. Inspecting the db tables, it looks like the update script updated the backend field for _staff table but did not update it for the _user table. The _staff table backend field updated to ldap.p1i2 but the _user table stayed ldap.client so when I manually update a user to ldap.client.p1i2 that user can login. Interesting the user side logs right in with no issues.
I checked the _file table and found both the B and L files. Both files have data in the _file_chunk table. From the web interface I changed back to the stock logo and backdrop. I then deleted the custom entries. Verified the stock images are loading correctly. Uploaded a new logo and verified it saved to both tables. The logo shows as a broken image in the web interface. Changed logo for both Client and Staff to the custom logo and saved changes. Then tried loading the site in an incognito window, logo is broken.
I do have a couple tweaks I have done to a couple php files but they are really basic things like changing wording of text.
Thanks for the reply. I'll answer each one here.
I thought the same thing about the config file but looking at it using diff there were so many other things in the new version I was afraid because I'm so far behind that something wouldn't work right if I kept the old file.