Users sometimes get page content from other users while keeping their own URL!

[Marcel van Langen]

Hello all,

I hope someone can share some thoughts on the following problem...

Ik work on an application with a lot of users. It's a MS server 2008 with SQL Server 2012, Lucee (was Railo). We'll be migrating to a MS 2012 server soon btw...

Problem: sometimes a users gets the content that was meant for another user. You could say it had something to do with caching, scoping, session, but the strangest thing is: it doesn't even have to be the same page!

So user A asks for a list of clients. Maybe he then receives a detail report that was meant for user B. But in his browser he sees the URL that he requested! So the content doesn't match the user (user A sees something from user B) but it also doesn't match the URL (his browser says 'list of clients', but his content says 'detail report')!

I'm at a total loss here. Any thoughts that could help me would be greatly appreciated!

Marcel

[Jon Clausen]

It could still be a caching/scoping issue, depending on where variables that assemble the request are cached, or whether singletons are used that are incorrectly using the variables scope for request-level data.  

Is there any downstream caching at the web server level that might be causing the issue.  If you’re using IIS or Apache rewrites with a single index.cfm as the target you may have some tweaking of the rewrite rules to ensure the web server cache isn’t becoming confused.

Jon

--
Love Lucee? Become a supporter and be part of the Lucee project today! - http://lucee.org/supporters/become-a-supporter.html
---
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/ab6c5af5-5d6a-4499-baf8-ef1b0c045799%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brad Wood]

I second Jon's suggestions.  Based on the architecture of your app, this could be as simple as a var scoping issue somewhere mixing up rendered content.  The majority of the time I see this, it's some sort of HTTP proxy/cache that a network administrator installed somewhere.  They typically deny it at first, but after weeks of pulling your hair out, they're like, "Oh, you mean THIS gate key!"

If you can duplicate the issue, inspect the HTTP headers for clues. Also if you have access logs, cross reference the timestamps that the users made the requests.  If user A and user B made the request at the exact same time and hit the same server, it's likely an issue in your app.  If they're requests are sevearl minutes apart, it's likely an overactive cache.  Actually, on that note, add some cache invalidation headers temporarily to your site and see if it goes away.  Most cache appliances will obey those.

Thanks!

~Brad

On Friday, January 22, 2016 at 11:48:40 AM UTC-6, Jon Clausen wrote:

It could still be a caching/scoping issue, depending on where variables that assemble the request are cached, or whether singletons are used that are incorrectly using the variables scope for request-level data.  

Is there any downstream caching at the web server level that might be causing the issue.  If you’re using IIS or Apache rewrites with a single index.cfm as the target you may have some tweaking of the rewrite rules to ensure the web server cache isn’t becoming confused.

Jon

On January 22, 2016 at 10:26:55 AM, Marcel van Langen (vanlang...@gmail.com) wrote:

Hello all,

I hope someone can share some thoughts on the following problem...

Ik work on an application with a lot of users. It's a MS server 2008 with SQL Server 2012, Lucee (was Railo). We'll be migrating to a MS 2012 server soon btw...

Problem: sometimes a users gets the content that was meant for another user. You could say it had something to do with caching, scoping, session, but the strangest thing is: it doesn't even have to be the same page!

So user A asks for a list of clients. Maybe he then receives a detail report that was meant for user B. But in his browser he sees the URL that he requested! So the content doesn't match the user (user A sees something from user B) but it also doesn't match the URL (his browser says 'list of clients', but his content says 'detail report')!

I'm at a total loss here. Any thoughts that could help me would be greatly appreciated!

Marcel

--
Love Lucee? Become a supporter and be part of the Lucee project today! - http://lucee.org/supporters/become-a-supporter.html
---
You received this message because you are subscribed to the Google Groups "Lucee" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com.

[Paul Klinkenberg]

Hi Marcel,

Do you have any after-request output manipulation going on, like changing the contents of getPagecontent().getOut().toString() in onRequestEnd? I would suspect a scoping issue with something like that. 

Or maybe the whole page/body output is first saved in a variable with cfsavecontent, which has a scoping issue somewhere.

Just some guesses, but it heavily smells like a scoping issue to me...

Kind regards,

Paul Klinkenberg

------------

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/etPan.56a26b6d.2f732a8c.e80d%40jonclausen-mbp.local.

[Geo Geo]

Used to have similar issues in the past, under ACF.

It then came out that the IT admin of my customer had to do some sort of configuration on their firewall - as it was extensively caching the requests hence data of one user could be found on the other's account. It's strange really and perhaps the only real way to handle this is to use entirely unique URLs (by using tokens, random strings on your URLs, pay special attention to Ajax requests).

not sure that the firewall setting was - i m not really a network admin but it's been confirmed that this was the reason.

Hope this helps.
George

[Bilal]

In cases where you restart Railo/Lucee without restarting IIS you can run into a situation where you will have cached content from previous connections displayed to users when using a connection pool.

You can disable connection pooling to prevent this or  follow a shutdown order that will also recycle the connection pool like this: first shutdown IIS, then, then shutdown Lucee.

To disable connection pool set:

<MaxConnections>0</MaxConnections>
In active connector setting file (BonCodeAJP13.settings), normally located in c:\windows for lucee.

HTH,

Bilal

[Brad Wood]

Bilal, are you saying this is a bug in the Boncode connector?  What can be done to remedy it so connection pooling can be left enabled.  

Thanks!

~Brad

ColdBox Platform Evangelist

Ortus Solutions, Corp 

E-mail: br...@coldbox.org

ColdBox Platform: http://www.coldbox.org 

Blog: http://www.codersrevolution.com

--
Love Lucee? Become a supporter and be part of the Lucee project today! - http://lucee.org/supporters/become-a-supporter.html
---

You received this message because you are subscribed to a topic in the Google Groups "Lucee" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lucee/-EDw2emoLVs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to lucee+un...@googlegroups.com.

To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/e3085cb0-6a55-4f16-bb0f-766e311ca9fc%40googlegroups.com.

[Alex Skinner]

Hi,

I was thinking the same as Bilal but depending on the age of the installation there was also a bug I believe where if the IIS timeouts and Railo timeouts were out of wack then the next request would get the previous requests content.

So worth checking you are on the latest version of the boncode connector as well.

Cheers

Alex

--
Love Lucee? Become a supporter and be part of the Lucee project today! - http://lucee.org/supporters/become-a-supporter.html
---

You received this message because you are subscribed to the Google Groups "Lucee" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.

To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/e3085cb0-6a55-4f16-bb0f-766e311ca9fc%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Alex Skinner
Managing Director

Pixl8 Interactive, 3 Tun Yard, Peardon Street, London SW8 3HT, United Kingdom T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: in...@pixl8.co.uk

Follow us on: Facebook Twitter LinkedIn

CONFIDENTIAL AND PRIVILEGED - This e-mail and any attachment is intended solely for the addressee, is strictly confidential and may also be subject to legal, professional or other privilege or may be protected by work product immunity or other legal rules. If you are not the addressee please do not read, print, re-transmit, store or act in reliance on it or any attachments. Instead, please email it back to the sender and then immediately permanently delete it. Pixl8 Interactive Ltd Registered in England. Registered number: 04336501. Registered office: 8 Spur Road, Cosham, Portsmouth, Hampshire, PO6 3EB

[Bilal]

Brad,

we could investigate something here but the behavior has been documented in context with connection pools for a while.The documentation also highlights the changes one is to observe when using connection pools

e.g.:

During startup: First start Tomcat, then IIS (Application Pool)

During shutdown: First shutdown IIS (Application Pool), then Tomcat.

In a connection pool, the connections are purposefully kept alive even after the communication has completed so they can be quickly reallocated to future calls. If the shutdown/startup order is not followed the network stream cache may contain consistent call data that will be retrieved with the next call on the connection (If the connection is inconsistent, it will already be recycled).

In earlier versions we always created a connection pool (to maximize performance). From 1.0.22 onward we disabled the pool by default so that we maximize compatibility. 

I made the assumption here that since this was an upgrade, a previous set of configurations might have been kept and could cause this. Not knowing or seeing the code I would recommend that we disable the connection pool first and go from there. If it is already disabled, then we would need to look at different factors.

HTH,

Bilal

[Marcel van Langen]

He Paul,

Long time no see! That's actually a pretty good point. I have an OnRequestEnd.cfm that processes the output. It basically cleans up some things and adds some things. I've directly turned off this processing, can't wait to see what this does for the problems... Fingers crossed! Thanks for your input!

Marcel

Op zaterdag 23 januari 2016 19:10:52 UTC+1 schreef Paul Klinkenberg:

[Marcel van Langen]

Hello all,

Thanks for all your input. Very helpful indeed! Based on your input I've already skipped some code in the OnRequestEnd that basically did some processing on the output data. Since we get a new server in two days, that might make a great update (no history of previous installs, older versions of IIS etc.). So, I'll keep my fingers crossed and let you know what happens in the upcoming days. Thanks again!

Marcel

[Vikas Patel]

I've just seen this case yesterday. I was having a batch processing which took 2 days. I am keep firing a page and page will respond a json body which includes some count. I face this issue around 5 to 6 times.

All the time I get the output from cfexecute command which I just fire it to start my casper scripts. You can see that casper script's console output is added to my page which is completely different.

P.S. I use Lucee 4.5

[Marcel van Langen]

Just a little update. The problem seemed to be that the application (it's an oldy!) was still using the Fusebox 2 Framework. There were some rewrites within the framework, but that seemed to be the problem. In the last 2 weeks we converted the application to a new framework (custom since we wanted to maintain the structure of the application). That has been online since yesterday and things are looking good so far...

I do have some experience that I'd like to share though.

- There are users that work at the office, close their laptop (still active) and open it at home. Since the session can then be still active, they have another IP address but the same session
- There are groups of users that work in a shared office, all through VPN. I'm not a VPN expert, but it seems that users get appointed IP addresses by the VPN that can change during a session

Both of these possibilities caused problem within our application, since we did an extra check on the IP address to see if the user was who he said he was... Maybe there are even more possibilites why a user can have a changing IP address during their session... Obviously this is not the cause (I think at least) that a user gets content that was meant for another user, but it is something to keep in the back of your head....

Marcel

[Brad Wood]

I wouldn't recommend counting on the user IP not to change.  I've seen a number of cases in which that happens legitimately from govt networks that route HTTP/HTTPS out different gateways, to users behind caches (like AOL back in the day) that can switch around.  The cookie should be enough to tell you if it's the same user hitting your site.  If you want to prevent CSRF (cross site request forgery) then look into the new-ish CSRF tokens in CFML.

Thanks!

~Brad

ColdBox Platform Evangelist

Ortus Solutions, Corp 

E-mail: br...@coldbox.org

ColdBox Platform: http://www.coldbox.org 

Blog: http://www.codersrevolution.com

--

Love Lucee? Become a supporter and be part of the Lucee project today! - http://lucee.org/supporters/become-a-supporter.html
---

You received this message because you are subscribed to a topic in the Google Groups "Lucee" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lucee/-EDw2emoLVs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to lucee+un...@googlegroups.com.

To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/2f6cc346-72db-48b4-98f9-dff41c7c5028%40googlegroups.com.

[Denard Springle]

- There are users that work at the office, close their laptop (still active) and open it at home. Since the session can then be still active, they have another IP address but the same session

Best practice is to automatically time out sessions after a specified period of time (e.g. 15 minutes, for example), so most users should have to log back in by the time they get home (depending on how far they live from work, and what the timeout is set to) and not be able to 'open up their laptops and continue working'

Best practice for changing IP addresses is the same - you should force the user to log back in if the IP changes, rather than serve them any content from an existing session.

As both you and Brad note, however, IP's can (and do) change - though typically not within the same session, there are exceptions in multi-homed networks. If the IP address changes, so should the session (and thus, force a login). I suspect your VPN users simply time out on the VPN (idle 15 mins or so) and the VPN kicks them off - when they log back in they get a different IP from the VPN gateway.

In either case, I would either check for IP changes and force a login on change, or rely on the cookie(s) to manage sessions across multiple IPs (and remove the IP checking code).

As Brad also points out, for CSRF protections, look at CSRFGenerateToken() and CSRFVerfiyToken() functions.

None of this explains why some clients were getting other clients content, of course. There are lots of reasons this could happen - session corruption by poorly written code is the most likely culprit in most cases... which it sounds like was the case here ;)

-- Denny

[Jason Brookins]

Unfortunately is seems the built-in CSRF functions don't work if you use J2EE sessions; all you get is the following message:

this function only works with CF Sessions

I posted here almost a year ago about this very thing, but didn't get any response.

- JB

[Samuel W. Knowlton]

Did you ever make a ticket for this? This is an issue for us as well (though a small one).