Posts Tagged ‘tricks’

Clear the recycle bin for all users

Tuesday, September 11th, 2012

Here’s an interesting problem I’ve run into recently with a Plumtree / ALUI / WCI server (but, of course, applicable to any server or desktop). A portal server was running out of disk space, and using the Cool Tool WinDirStat, I saw that D:\Recycler\ – the hidden Recycle Bin folder – was sucking down a ton of disk space, but my Recycle Bin was empty.

I knew deleting files in Windows simply moved them to a hidden folder (\Recycler – one hidden folder per drive), but didn’t realize it maintained a separate deletion history for each user. Turns out, since a lot of Systems Administrators had accessed the system before me, their recycle bins were consuming space – but because the folder was hidden, I couldn’t clear those out through Windows Explorer.

The solution was a Google Search away, and I came across this article from LifeHacker: Force Windows Recycle Bins to Empty for Every User on a System. This command simply deletes that hidden folder, effectively purging everyone’s recycle bin and reclaiming the lost space:

rd /s c:\recycler

Remember to run it as Administrator, and you may find some unused space you never knew was available. And don’t worry about breaking the Recycle Bin – Windows automatically recreates the folder when it’s not present.

Use File:New Session to log in with another account

Thursday, May 24th, 2012

Here’s the situation: you’re a system admin logged in as administrator, but you need to see what the user interface of your portal looks like as a guest or other user. As you know, sessions are stored on the server, and web requests from your browser send a cookie to map to that session. If you use CTRL-N to open a new browser window, those cookies still get sent to the server, and you’re still logged in with that account.

But, in IE if you go to File: New Session, a new browser window will open, and the cookies will be cleared and maintained separately.

Boom – 2 browsers, 2 sessions:

Run explorer.exe if Remote Desktop Doesn’t Work

Monday, June 20th, 2011

If you’re using Windows for your WebCenter platform, you no doubt use Remote Desktop to RDP into the servers every now and then to run updates and diagnose issues.  Sometimes, though, you just get a blank window:

Strange right?  Well, for this particular anomaly, there’s no need to call up IT to reboot the stubborn box.  Just run explorer.exe under the “Programs” tab in the Remote Desktop Connection properties window:

Boom! – system tray is back:

Communicating Directly with WebCenter Interaction Search Server

Wednesday, October 6th, 2010

Years ago I wrote about checking the Plumtree (ALUI?) Search Server Status The Hard Way.  And I just let it go.  A couple days ago, I told you about a great webinar on Oracle’s support site, and it took that great presentation for me to put two and two together: communicating directly with the search server is possible for more than just “checking its status the hard way”:  once you know how to connect to the port and issue commands via Telnet, you can do ALL KINDS of stuff.  Anything, in fact, that the portal can do – and more.

It turns out that WebCenter Interaction – the portal, IDK, custom code, you name it – is just building complex text queries under the covers based on the actions a user performs (such as typing a search term in the search box).  And you can see these queries when you run PTSpy (Turn on INFO for the SEARCH component):

Taking this search string and adding the (secret?) key, you can compose an identical query:

KEY redacted (((NAMESPACE english BESTBET “matt chiste”) TAG bestbet OR ((ptsearch:”matt chiste”) TAG phraseQ OR ((ptsearch:matt or ptsearch:Matt or ptsearch:Matt_) order near 25 ptsearch:chiste) TAG nearQ OR ((SPELLCORRECT (ptsearch:matt) or ptsearch:Matt or ptsearch:Matt_) and SPELLCORRECT (ptsearch:chiste)) TAG andQ)) AND (((ancestors:”dd1″)[0]) OR (((subtype:”PTUSER”)[0]) OR ((subtype:”PTCOMMUNITY”)[0]) OR ((subtype:”PTPAGE”)[0])) OR (((subtype:”PTGADGET”)[0]) AND ((gadgetsearchtype:”bannersearch”)[0])) OR ((@type:”PTCOLLAB”)[0]) OR ((@type:”PTCONTENT”)[0]))) AND (((((@type:”PTPORTAL”)[0]) OR ((@type:”PTCONTENTTEMPLATE”)[0]) OR ((@type:”PTCONTENT”)[0])) AND (((ptacl:”u200″) OR (ptacl:”212″) OR (ptacl:”211″) OR (ptacl:”207″) OR (ptacl:”202″) OR (ptacl:”201″) OR (ptacl:”51″) OR (ptacl:”1″))[0]) AND (((ptfacl:”u200″) OR (ptfacl:”212″) OR (ptfacl:”211″) OR (ptfacl:”207″) OR (ptfacl:”202″) OR (ptfacl:”201″) OR (ptfacl:”51″) OR (ptfacl:”1″))[0])) OR (((@type:”PTCOLLAB”)[0]) AND ((istemplate:”0″)[0]) AND ((collab_acl:”- \~ 1″)[0]))) METRIC logtf [1]

Then, you telnet to the search server port and paste in the text.  Search will respond with an XML formatted reply (in this case, no results):

Of course, once you have this revelation, you can see how the search text can be tuned based on the folder you’re looking for, the ACLs you want to check, or any other number of parameters.

The other startling revelation is that security is applied at the portal tier, and not the search server tier. That is, if I’m a bad guy and I know that key, and I know the query format, I can construct a query that goes against the search server to circumvent any security that has been applied to cards. Notice there are no credentials or login token passed in the query for the search service to check. Now, before you get all up in arms about this being a major security vulnerability, I offer some counter-points:

  1. Anyone with any knowledge of network sniffers or tunnel tools could easily find this key, as the traffic is not encrypted - ”Security through obscurity” is not valid security.  However, I don’t consider this a fundamental design flaw or major security hole, and it is no doubt not the security that the Plumtree engineers had in mind when they implemented this. Instead, the search server should reside in a DMZ, and the port shouldn’t be open within the general network anyway. The port is NEVER to be opened to the Internet (try it on my site – “telnet 15250″ doesn’t work).
  2. Even if someone did have this secret key, and they had network access to the search server port, and they knew the search format, and they knew how to craft the request to omit ACLs, the most they could get was search results they didn’t have privileges for – not the documents themselves.

How can this be applied in a real-world scenario?  Stay tuned!

Cool Tools 10: Base64 Decoder

Thursday, September 16th, 2010

Generally, my Cool Tools articles feature tools that are novel, unique, or otherwise helpful when managing WebCenter Interaction portals, or other applications that can help augment (or – dare I say, replace?) it.  Today’s Cool Tool is in a category where apps are a dime a dozen.  So, let’s call, uh,’s Base64 Decoder a Cool Tool:

Why highlight a dime-a-dozen online app that’s pretty much just a free online tool?  Because today I’m going to explain a bit about how Basic Authentication works between the portal and remote tier, and show you a trick to answer a question that you may have come across during your portal administration:  what password has been configured for the “authenticationid” in the portal for ALUI Publisher Remote Server (or Collaboration Server, for that matter)?  In the process (after the break), hopefully you’ll get a little insight into why it’s not all that secure in and of itself. (more…)

Typing PTSpy filters occasionally works

Monday, May 31st, 2010

As you likely know, PTSpy messages are UDP messages generated by all services in the WebCenter stack. PTSpy / WebCenter Logging Utility is just a receiver for these messages.  Things can go wrong some times, though: UDP is not a guaranteed message protocol, and log events may be lost.  But more importantly, occasionally these applications don’t report themselves properly, and as a consequence, PTSpy doesn’t display them in the filter list.

What I didn’t know until recently is that just because an application doesn’t show up in the message sender list doesn’t mean the application isn’t generating messages.  Typing the name of the sender into the text field sometimes works too.  Take this example; I was trying to diagnose a problem with the Portal Notification Service, but the CNS didn’t show up in the list of message senders:

In the CNS log, I found this line:

INFO   | jvm 1    | 2010/05/09 19:35:26 | Using OpenLog Application Name ‘cns.NRC372DR.plumtree’ for CNS SPY logging

So on a whim, I tried just typing that string into the “Message Sender” field.  That couldn’t possibly work, could it?  I mean, if PTSpy doesn’t detect the Sender, it won’t capture messages being generated by it, right?

Glad I was wrong on that one:

When was that PAGE modified?

Sunday, March 21st, 2010

Years ago, I had a requirement to add “Content Last Modified” text to ALUI portal pages being served as a public web site. When a portlet was updated, this text needed to automatically update and be displayed inline for each Published Content Announcement portlet. Of course, this is pretty straight-forward; we just needed to insert the following tag into the Publisher Presentation Template:

<div align=right>
  Item last published on
  <pcs:value expr="modified" format="MM/dd/yy">

The problem is, the portal isn’t a web site – it treats each portlet as an individual component on the page, so users aren’t really looking at the “page last modified” date, they’re looking at the “content item last modified” date. Get two Publisher portlets on the same page, and it looks a little weird with the “Last Published” date associated with the portlet showing up in the middle of the page: 

Recently, I came across a similar requirement for “Content Last Modified” text, but we wanted to avoid the text showing up more than once on pages with more than one portlet. The trick? Hit that “read” link.