We are currently having an issue with cache settings on a shared workstation at one of our client sites. Basically, they had set their IE browser on their machine to "never" for when to check for new versions of a site. This causes some of our pages to show another user's data after one user logs out and logs back in. What are my options to prevent this type of behavior, aside from telling the users to not use that setting (which we can never really guarantee). The site is an asp.net 3.5 site.
I know one option is to set the page to never cache, but that will also cause users to lose the back button functionality on a lot of the site. So any other options would be helpful.
If you set caching to be on (from the server) you won't loose back button functionality, its just that clicking the back button will make a new request to the server rather than just displaying the page from cache. This is more secure, because it means if someones signs-out, another user can't click back to see what they had on their screen previously.
Related
I am implementing a bookmarking service (think Instapaper) using Firebase as a back end. Mostly it's working great, however I'm running into one major problem.
A core part of the service will be a bookmarklet that allows users to bookmark pages they are currently viewing in their browser (again, like Instapaper's: https://www.instapaper.com/save).
The first problem I encountered when implementing this was that even when a user is logged in on my firebaseapp.com page, that user was not showing up as authenticated when the javascript from the bookmarklet was fired. I figured out this was most likely due to cross-domain issues, so I next implemented an iframe-based solution. The idea being that the url of the iframe is hosted on my firebaseapp.com site, allowing the currently-logged-in user to show up as authenticated.
This works great in Chrome and Firefox but fails in Safari when the security setting for cookies and website data is set to "Allow from websites I visit" rather than "Always allow" (asking users to switch that setting to "Always allow" is not practical).
Is there any solution to this problem? Forcing users to log in every time the bookmarklet is clicked on a new domain would be highly inconvenient. I'm basically out of ideas at this point (and starting to get out of my depth on the web dev side of things).
Thank you so much for any help!
Here is the problem that I'm having. Often times, I cannot login to my Plone site. Other users have the same issue as well. Basically what happens is that when I click "Log In", the web page just refreshes but it doesn't log me in. In order to correct this problem, I had to clear the browser history and cookies in order to log in successfully. Sometimes I had to do this a few times in order to work. I would like at least 50% of the time I had to clear the history before I can login. Other times, it just works and it logs me in without any issue.
This problem started quite some time ago, perhaps almost a year now. I just never had time to look into it. However it seems like this problem is related to newer version of web browsers because I never had this problem before around one year ago.
I'm running Plone version 4.0.4. Can anyone suggest how I should troubleshoot this problem? Should I upgrade a particular component within my Plone setup?
FYI, I'm using the building authentication component and not anything external like LDAP. I manage my users in Site Setup -> Users and Groups.
Thanks in advance.
Things to look into:
go to /acl_users/session/manage_propertiesForm and check the settings here to make sure they make sense
check cookie settings for if they are valid on non-ssl and that you are logging in via ssl urls.
use a web browser web inspector(like chrome) and inspect that login cookies are set properly after you're logged in(look for the __ac cookie)
Finally, look into your caching. If you're using plone.app.caching, make sure to NOT cache for logged in users. If you're overriding caching at the web server, make sure you're not caching when the __ac cookie is present.
If you're not caching at the web server, make sure cache headers for the browser are also getting set appropriately
inspecting caching will also require using a browser to inspect the headers getting returned
I've been tracking to tackle this issue and narrowed it down, but first a little description:
I have a website that a client would fill out, some basic text boxes, bullets, and dropdowns. They click submit and the information they submitted (nothing sensitive) is Response.Redirect(ed) to another page which has text boxes that are populated by the information included in the redirect. This page also prints itself for the client to sign.
The issue started when I added one more field to the redirect page so that it appears as well when printed. It simply does not appear on the page or the print out and I cross-checked the properties with all the other textboxes and everything is the same. Now, I did narrow it down in that the new textbox does appear when using the built in debugger for MS Visual Web Dev 2010 Express but it does not appear when I host the website on the local IIS server. From here it seems to be obvious that the issue is a setting on the IIS service.
To the question: What setting in IIS would cause a newly added textbox to not appear under the circumstances mentioned? Also, am I approaching this website as a whole in a round-a-bout way i.e. instead of redirecting to another website the populates data, prints itself, and redirects back to the host page is there an "internal" form I can have the data sent to and print from there?
The issue was that I setup the ISS server/website under and an administrator account with the website being under a folder on the desktop. I overlooked this fact and copy/pasted the website folder to the desktop of a different non-administrator account and so naturally none of the changes were actually showing because IIS wasn't even pointing to that website folder of the non-admin account. Once I dumped the modified files under the proper folder under the admin account they finally appeared in production.
I am in the process of moving my drupal site to a new IIS server. I had it running perfectly on one server. I disabled all non-core modules, turned off clean urls, put the site in maintenance mode and moved the files and database to my new server. I am able to bring the new site up fine. I can view the main page as well as other content. I can even create new content.
However, whenever I try to access the admin page, I am getting a 500 error on the server. I am not getting anything in the server logs to indicate what the problem might be. Does anyone have any idea what might be going on?
Thanks for any thoughts.
Is the menu router menu system not rebuilt correctly?
Try getting to the Modules page, Menu page, or run cron.
There could be many reasons why you cannot access the administrative pages, including the fact the database tables have not been correctly moved.
Check the content of the table users, and verify the user account for the "super user" (the one with user ID equal to 1) has still the user ID equal to 1. That is a particular user that has automatically any permission; if the user ID is not 1 anymore, then the account becomes a normal user account, and it needs to be expressly allowed to do anything.
you don't need to disable clean urls, this is how your enable them in IIS:
http://learn.iis.net/page.aspx/505/install-drupal-on-iis/
could be something to do with clean urls, i also had this problem when recently removing my website to IIS, clean url's fixed this issue!
I'm using the ASP.NET Login control and have been doing so for a couple of years on a particular site with success. Out of the blue, in the dev environment, this control has stopped working and is now bouncing me back to the login page.
Using source control I've reverted recent changes that might have been the cause but no luck. I've stepped through the code and have checked that the e.Authenticated property is correctly being set to true and that the ReturnUrl is correctly specified on the params.
Any ideas about where to look next to try and figure this out?
After logging in are you being redirected to a page that you don't have authorisation for?
I would check the following...
Cookies still set in the browser
SSL settings in conjunction with http
not forwarding onto https
Cert issues (old, new, expired)
Changes in the domain that the user
is authenticating to
Essentially, check everything except
your code, it works like you said.
;-)