I'm having a strange problem and no luck debugging.
I was tasked with writing a JSR168 compliant portlet to search a database. When you open the portlet, you're given 6 search boxes for different criteria to search several thousand records. Once you press search, it brings up another page (it keeps the first page and uses <jsp: include> for the second page so users can see/change their search terms) with the search results. From the search results page, the user can click on one of the results (which redirects to a new page) and get more detailed information about it.
All of that works. The problem is when the user wants to search again.
When I developed this, I used LifeRay installed on my local machine. Everything works perfectly in IE, Firefox, and Chrome. However, when I deploy it to our development portal (IBM WebSphere), it doesn't quite work in IE. In Firefox/Chrome, when a user is on the detailed information page, they can hit back on their browser and it loads a cached version of the search results. Perfect, because this content rarely changes.
However, in IE, when they click the back button on the detailed view, we get a "Webpage has expired message". I've tried every caching setting in the portal settings for the portlet as well as the page, but haven't had any luck.
Anyone have any ideas?
There are settings at the portal level too.
Check out following link
http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/index.jsp?topic=/com.ibm.wp.ent.doc/wps/adbakbut.html
You could try tweeking some of these paramters as required by your portlets
The "Webpage has expired message" in IE indicates that you did a POST. You could try using a GET, which should not have this problem on "back" command.
You should install WebSphere Portal on your developer machine and test locally before going to another environment.
Related
I want to create a share button for Linkedin, the GUI button is all set up, but it doesn't work when clicking it. I researched a bit and came to the conclusion that using the same sharing mechanism, other sites work but mine doesn't.
I narrowed the problem down and now I'm trying to figure out why google.com works but my site doesn't. I don't use my real company website because it's personal information, but it's a website that has been on the internet for more than 10 years (in case this information is useful). When I go to the links, my website throws an error, but Google works fine.
Ⓧ https://www.linkedin.com/cws/share/?url=https://www.my-company-website.com
〇 https://www.linkedin.com/cws/share/?url=https://www.google.com
Is there any pre-requisite I'm missing, which makes my site not work?
I realized my server was blocking Linkedin (to reduce traffic from Linkedin bots). That's why it wasn't working.
As hint: I was working on closed webpage (for outside users) and that also causing problems with Linkedin share button.
Hint 2: Website uses Lets Encrypt! SSL and information mentioned here is a fake news https://wordpress.org/support/topic/linkedin-share-button-not-working-3/ Work's fine!
If you ever get stuck on trying to figure out why your page simply doesn't populate nice preview data on your LinkedIn share page, then check out the LinkedIn Post Inspector.
Insert the URL of your page (i.e., example.com), not the URL you are using to share (i.e., linkedin.com/share?url=example.com). You'll get detailed information on how your site will appear and why, like, for instance, sharing wikipedia.org...
Hope this helps someone else with a LinkedIn share issue!
I have configured my Websphere Liberty server to support the Admin Center as described in the IBM Knowledge center.
I am running WAS Liberty version 17.0.0.1 on Windows 10 from an eclipse Neon environment (ie. on localhost). I connect with the URL (http://localhost:9080/adminCenter) from Chrome (version 61).
It puts up a login page (not great looking but serviceable)
I enter my credentials and click Submit and I am taken to the login.css webpage.
Within the Chrome developer tools, I can see an error message on the console indicating the GET for favicon.ico failed.
Then I can go to the browser address bar, manually change the URL to point to the adminCenter and it takes me to the Toolbox page for the Admin Center. From there I can select the Server Config graphic and see my server data.
Can anyone identify what I have configured wrong that is causing the AdminCenter to display the login.css webpage rather than re-route to the adminCenter webpage after I login?
Additionally, if anyone can direct me to instructions on how to put up a more user-friendly login page, I would be very grateful. (I'm doing my client-side application development in Angular. The only information I've found so far for customizing a login page with WAS Liberty references creating a login jsp page which I don't know how to do. (Sorry, I don't have enough reputation points to provide the URL for this) I'm still learning Angular and client-side development.)
Have you previously accessed a different version of Liberty and accessed its Admin Center on that browser? If so, your browser (or something else in the network pipe) could be caching old files causing such issues. When something like that happens, easiest way to check would be to try and open the page (the url you're using is correct, and it correctly redirects you to HTTPS) in a private/incognito tab/window of the browser (ctrl+shift+n for most browsers), or a different browser. Alternatively, you can clear the cache of the browser you're using for that page/domain (which would also be the actual fix if the cache is indeed the problem.)
I have a number of virtual applications under one site, all of which have the same issue. Whenever you are at the root of the application (~/) postbacks do not fire, the page just refreshes.
Here are some samples (all their own virtual applications):
Clicking on "Login" link does not redirect to Login.aspx page
http://designbyssi.com/designbyssi.com/projects/air-savings/02/
http://www.designbyssi.com/designbyssi.com/projects/life-furniture/06/
Entering username / password, and then clicking "login" / "go" does not log a user in
http://designbyssi.com/designbyssi.com/support/
http://www.designbyssi.com/
For some reason, if you add "Default.aspx" to the end of any of the pages above the postback works as expected (eg. http://designbyssi.com/designbyssi.com/projects/air-savings/02/Default.aspx). I've been Googling this for a while now and I found a few articles, though none of them have helped.
Here are the articles I've managed to find:
Why won't postbacks work on my domain root?
http://forums.asp.net/t/1735380.aspx/1
http://forums.asp.net/t/1482960.aspx
I'm not using any type of URL rewriting, they are all web form applications, and I'm on a Godaddy shared hosting account.
Any ideas on what might be happening, or what I need to do to fix it?
I had the same issue recently where my dev environment was setup in integrated mode while production was in classic mode. Postbacks in dev were not working when going to the root of the site but would work when going to Default.aspx.
I simply changed my dev environment to use classic mode for now. Also, this problem does not necessarily have anything to do with URL rewriting.
Since you are on shared hosting, you probably can't do that but these links may help.
Postback doesn't work with aspx page as Default Document
Event Handlers Might Not Be Not Raised in a Default Document in IIS 7 or IIS 7.5 Integrated Mode?
I have an application running in Azure (trial account). So far so good, everything has been nice, except for a long deploy times (10-15 minutes).
I've done a deploy recently and got a lot of weird bugs I cannot trace. For example, if I log in and thus a cookie is created (I use FormsAuthentication) all I get from the application is a blank page, as in, absolutely nothing is sent to the browser. The application works fine in the ASP.NET Web Dev Server, IIS Express, even the Azure Emulator!
What could be the issue? Searching the web hasn't been much help, with only a couple of unrelated issues.
I tried logging into the site (if I correctly understood from one if the comments, the url is versulo.com) and I didn't get any blank page with 404 status code.
However, there is another problem I spotted. Your site seems to be implementing caching inappropriately. The main page, the one from which you trigger the login and which is dynamic in nature contains an Expires header set at 5 minutes after the pages first load. That means that each call or redirect to that page within 5 minutes since it was first loaded, will be served from the browser's cache.
Because of that, after I login into your application I am redirected back to the home page which looks like I am not logged in. If I force a F5 refresh on the browser, then the page will indeed show me as logged in.
If instead of a refresh I try to login again (which is what I did in my first trials, since it looked like the login didn't work in the first time), I am getting an error page with the following message:
Sorry, there has been an error on the server.
500
The page looks like an application error page and even if it displays the 500 number, it is actually served with an HTTP 200.
So, while I am not 100% sure if this is also the cause of the problem described by you, you should remove the Expires headers from the dynamic pages your application is serving.
This can be because you're combining Forms Authentication with multiple instances. Are you using multiple instances? If that's the case, could you:
Try to change it to 1 instance. Does this fix the issue?
Try to make the following change to the web.config (configure machineKey): http://msdn.microsoft.com/en-us/library/ff649308.aspx
some partial views are not rendered at all;
Do you mean some pages are working fine, but others are not? It would be better if you can point out a pattern on what’s working and what’s not? For now, please make sure all referenced assemblies (except for default .NET assemblies and Windows Azure runtime) have Copy Local set to true. For example, MVC assemblies are considered as extensions to .NET, so please set Copy Local to true. In addition, you can also try to use Fiddler to monitor the requests to see what’s returned from the server.
Best Regards,
Ming Xu.
Could you provide a link to the application, or perhaps some source code?
When you say 'blank page', what is actually returned, a 404 / 500?
Have you inspected the IIS logs, or added some trace information to your code?
Have you tried accessing the service using it's ip address rather than domain name?
I've got a web service that, like most others, uses js and css files. I use the old trick of appending a version number to the js and css file like; ?v=123 and that gets changed every time we update the service on production.
Now, this works fine on all browsers, except for Chrome. Chrome seems to prefer it's cached version over getting the new one and therefor seems to ignore the appended variable. In some cases, forcing it to refresh cache (cmd+r / ctrl+f5) wasn't enough so I had to go into options and clear out the cache for it to load up the new content.
Has anyone experienced this issue with Chrome? And if so, what was the resolution to the problem?
Chrome should certainly treat requests with varying query strings as different requests; a cached result for style.css?v=123 should never be used for style.css?v=124. If you're seeing different behavior, please file a bug at http://new.crbug.com/ and post the bug ID here.
That said, I'd first check to see whether the page was cached longer than you expected. If a new version of the page itself wasn't downloaded, then it would still be requesting ?v=123 as the HTML wouldn't have changed. If you're sending long-lived cache headers with the page, it's certainly possible that Chrome is caching it more aggressively than you expected. If that's the behavior you're seeing, please star http://crbug.com/8742 for updates.
I had also same experience
You can user Ctrl + Shift + R for cache free browsing in both Chrome + Mozilla.
I have had this experience as well.
I run a membership site which displays content such as "You must be logged in as a Gold member in order to see this content" if they are not logged in or are trying to view content not allowed by their membership level. But even if the user is logged in, the user would still see "You need to log in", due to Google Chrome's aggressive caching. In Firefox, however, it works fine as I test logging in and out of all 5 levels of membership - each displaying the proper content.
While Chrome's caching problem can be solved by clearing the cache every time the user logs in and out, it would be really annoying to take that approach.