Answered WebSpeed newbie question regarding security

[RealHeavyDude]

OE11.3.1 in Solaris 64Bit SPARC
There is a first time for everything - this one is for me vs. WebSpeed ...

I've inherited some WebSpeed procedures ( CGI wrappers ) with the requirement to make sure they are protected from unauthorized cross-border access.

I am perfectly fine in implementing it into a single procedure in accessing the corresponding HTTP header holding the users location - courtesy of CAs SiteMinder.

But, I would prefer to have piece of logic that fires whenever somebody accesses any procedure on the WebSpeed Broker. So far I've seen that each request passes through web/objects/web-disp.p.

Is it a wise idea to create my customized copy of that procedure to ensure that the cross-border check is enforced? Is anybody willing to give me a hint if there is a better place/technique to do this?

Thanks in Advance and Best Regards,
RealHeavyDude.

 

[Stefan]

Great place for locking down requests.

The only gotcha, is that as soon as you customize this, that you will need to be extra wary of Progress updates.

See for example https://community.progress.com/community_groups/openedge_development/f/19/p/12200/44584.aspx#44584

 

[TheMadDBA]

Depending on your requirements (country list, ip ranges, user ids, etc) you can either modify web-disp.p or the cgi scripts. I prefer changing the cgi scripts when I can since it stops the request earlier.

I always make a new directory (custom) change the PROPATH to point there before DLC instead of changing the files under the DLC directory.

 

[Cringer]

Yeah we fell foul of that exact same error with a customised web-disp. But other than that it works a charm

 

[RealHeavyDude]

Thanks for the great responses!

Unfortunately modifying the CGI scripts is not sufficient as the logic is rather complex.

It involves

• The type of user ( client or client advisor )
• The jurisdiction a user wants to login to
• The jurisdiction the user is located
• Whether the request originates from within corporate network, offshore partner's network or the internet
• Whether the specific data room access is waived or partly waived for specific clients
• The users entitlements
• Last but not least - authentication strength ( weak or strong authentication )
• some other stuff

Most of the stuff is stored in a separate database to which the WebSpeed agents are connected. The result will be a client principal object stored in a seperate contect database.

Therefore I'll give the web-disp.p a go. Since I did a lot of customizing to now obsolete Progress frameworks like ADM2 and Dynamics in the past I am used to taking my own copies of the relevant code and place in the PROPATH before the original ones. Needless to say that I did run into the same problems as outlined in the communities discusion. That is one of the problems with third party frameworks - keep your customizations in-line with the evolution of the framework ...

Thanks, RealHeavyDude.

 

[Rob Fitzpatrick]

We also customize web-disp.p in our web applications. I heard recently from one of the web developers that he ripped out some old Progress ADM code from web-disp as it had memory leaks. Sorry I don't have specifics but I can try to get info from the developer if you need.

 

[RealHeavyDude]

Can it be that what the developers ripped out was where the code branched into the state-aware logic?

I never did use state-aware with an AppServer or WebSpeed Broker and I would not recommend anybody to do so. Therefore all our AppServer instances and the WebSpeed Broker instances are state-free or stateless respectively.

Therefore I am thinking about ripping out the state-aware code and generate an error message in the agent's log file instead to prevent anybody from doing something stupid like that ...

Thanks very much, RealHeavyDude.

 

[Rob Fitzpatrick]

Can it be that what the developers ripped out was where the code branched into the state-aware logic?

We always run stateless, so my guess would be no. But it's just a guess. I'll see if I can find out more today.

 

[TheMadDBA]

This kb describes the only memory leak I am aware of that is related to customizing webspeed.

http://knowledgebase.progress.com/articles/Article/P57966

Would also love to learn about another issue to add to the check list

 

[Rob Fitzpatrick]

Thanks TMD. Just talked to a developer, he says the issue you referenced is the one we dealt with.

 

[RealHeavyDude]

Thanks for you valuable input.

By the way, as a good practice, to bind all handle-based objects per default automatically to the unnamed widget-pool scoped to the procedure, I always use the create widget-pool statement on top of every procedure I code. From my point this is some sort of a last line of defense for a case when the corresponding delete object statement is missing for some reason. If you don't use that widget-pool, all handle-based objects per default get created in the unnamed widget-pool scoped to the session ...

Thanks, RealHeavyDude.