That shouldn't necessarily be a problem. I can't see why that would be. If you need to be logged in then the login page is automatically displayed in the place of the page you were trying to access. After the form is submitted to `Login`, the page is redirected back to the page.

Example of the process:

1. You're logged out
   
2. You access page `Home`
   
3. `Home` requires you to be logged in
   
4. `Login` is displayed instead of `Home`
   
5. Form submits to `Login`
   
6. `Login` is displayed (displaying notice of successful login)
   
7. `Login` redirects to `Home` after you're logged in
   
8. You access page `Home
   
9. `Home` is displayed

The problem is with Chrome and Mobile Safari. They both share a feature and that is cookies are not allowed to be saved under file://. While this has nothing to do with where my cookies are being stored, I believe since they both are the only browsers that do this, it may have something to do with it. I'm doing my research on this to try and figure out how to fix this. I may have to base64 all my cookies. I've read that Chrome isn't very forgiving when PHP makes simple mistakes when using setcookie()

Err, why would you be trying to save cookies under file:// rather than to @swivelgames.com, the normal place for your cookies? The only thing I can think of is local sandbox'd dev, which isn't the case for comicIDIOT et alia.

Yeah, that's why I'm confused. I'm just trying to find reasons why cookies would have trouble being set and overwritten and what not in Chrome and Mobile Safari. The only similarity would be they're both using webkit and they both do not allow cookies saved under the file:// protocol. I highly doubt that's the problem but yeah... just out of ideas at this point...

The odd thing is that it works perfectly fine whenever on localhost, but on the Swivelgames server it has problems. It may have something to do with cookies on swivelgames.com being different then on www.swivelgames.com?

It absolutely could be that! At one point I auto-forwarded via HTTP status 300 from cemetech.net/* to www.cemetech.net/* for several reasons, that among them; I'm not sure if the redirect is still in place.

Bingo! Logging in at swivelgames.com will redirect http://www.swivelgames.com/index.php for some reason. I've got to (1) fix that redirect problem, and (2) figure out why it's not setting the cookies across all sub-domains like it's supposed to.

I had a massive post prepped for submission on Stack Overflow, but I figured I'd see if you said anything. I figured I'd try something, and thankfully I found the source

Fair enough, glad you at least have the bug-finding half of the battle behind you, which for me is often at least if not more challenging than the second half, fixing it.

Indeed! That's always the hardest part

Along with the domain problem, which I apparently haven't fixed, IE8 is now displaying the same symptoms Chrome was in the very beginning of this mess. The user cannot log in... period...

Never in my life have I had so much trouble setting, maintaining, and deleting cookies. I really don't understand what is so unbearable about my code that these cookies are crumbling like they are. Maybe I didn't put enough starch in 'em

I give up for the night. I'll work with this mess tomorrow. *throws keyboard*

July 27th, 2010

• Located cookie bug problem
  
• Added fix for Chrome cookie bug
  
• Discovered IE8 login problems -- Cookie-related
  
• Added page title customization
  
• strict_agent_check causes problems in IE8 (non-static User Agent)
  
• strict_agent_check fix - Database row type to Text()

Well, I fixed the Chrome problem. But IE8 on Win7 is still being a bastard. Goodnight world. >.>

Meh, that sucks about IE8, your amusing cookie joke notwithstanding (I really hope you don't bake cookies; I think starch is not the ingredient you were thinking of ). Good luck tracing that one down.

I'd think it'd be water, no?

Also, glad to read it's been tracked down for the most part!

Water vs. flour indeed, for wetter or drier cookies. Hopefully the IE issue isn't too painful to track down. Cross-browser compatibility testing is the worst.

Starch, as in the type of ingredient, not the ingredient itself (Examples of starches: Rice, wheat (flour), maize (corn), potatoes and cassava (yucca)). Not enough starch in your cookies will cause them to crumble and not hold together. Starch works as an adhesive in cooking.

And cross-browser compatibility is quite a pain. Although, I didn't ever think I would have to deal with it on the backend level of web development. That's one reason I've enjoyed PHP so much... not having to deal with cross-browser compatibility

Tonight's game will be starting late this time, so I've got some time to code a bit and figure this out before then

BUMP
Double post... because I can. Suck it.


Fixed the IE8 problem. I've had a user-agent comparison going on for a while now to help with authentication between different browsers, but that had to be disabled. Apparently IE8 does not have a very stable user agent, so it's very dynamic. Therefore, you can't use it for any type of authentication what-so-ever. What a pain...

Sounds good, good luck. We already got in a few games earlier today with comicIDIOT, Dontar, and myself; I think you and Jonimus will hopefully be joining us later, and maybe rcfreak and Tribal as well. Any brainstorms?

Read above ^^,

Fixed the IE8 problem

The list of updates for the day. Scroll up



[edit]Fixed a silly mistake I made in the beginning. I had the user agent field type in the database as VARCHAR(255) instead of Text(). IE8 just had a long user agent, is all

July 28th, 2010

• Implemented stand-along module file support
  
• Wrote tiSAX client
  
• Fixed class autoload bug
  
• Updated live database to reflect module-support changes
  
• Optimized stand-alone module file support
  
• Synchronized live and offline versions
  
• Fixed minor incompatibilities

Everyone keeping up with Swivelgames.com, let me know what you think of the tiSAX module I just added to it

[edit]
July 29th, 2010

• Improved cookie declaration function
  
• Fixed OUAAT -- Minor variable rename error
  
• Fixed major user login bug
  
• Fixed "LOL" replacement minor bug [tiSAX]

Very nice; I've been enjoying testing out tiSAX on your site this morning, and I think you'll have pushed me to add nick highlighting here as well, although I've been meaning to implement it clientside.

Good to hear!

Thanks for testing it out and such. I was having some trouble with multiple users being logged in at once (OUAAT -> One User At A Time) with comicIDIOT, but I managed to fix that right as he got off. I'm glad you got on and were able to help test it out with me. Same goes to you, LucasW.

I appreciate all the help and support from everyone so far

Of course! Might I inquire as to what you discovered as the source of the OUAAT bug? I saw your note on that and was mystified at how that could possibly be working, other than accidentally emptying the sessions table every time a new session was created.

Actually, I md5 the $begin variable to determine the session id. The problem was that after I added constants.php to the file list and changed $begin to BEGIN, I forgot to update that line. So everyone was getting the same session id. That pretty much caused everyone to share the same session id and whoever had it last was the only person able to work with it. As soon as someone tried to login, their session would be voided because someone else had an active session using the same SID.

It was a minor mistake I overlooked. It was very confusion at first, though, because it showed the same signs as all the other login problems, except this one continued to persist. What tipped me off was that when AlexG finally logged in I was immediately logged out. I checked the sessions table and there was a ridiculous amount of entries containing the same SID