Skip to main content

How to stop direct access of a DSP?

Author: jason_zuvela@yahoo.com (jasonzuvela)

Hi

I want to embed a range of DSPs using DSP containers, but I don't want to allow users to access those embedded components directly. So they should only be accessible through a DSP container. Has anyone come up with a solution to stop someone from directly accessing a DSP (by typing the component id into the url)?

eg. http://server:port/uniface/wrd/COMPONENTNAME

I have tried looking into filtering urls in the http requests at a webserver level, through use of .htaccess or similar, but it doesn't seem like tomcat supports this kind of functionality. So far the only solution I have found is to put a http redirect in the DSP's <head>:

<meta http-equiv="Refresh" content="0; url=http://server:port/uniface/wrd/MAINCOMPONENTNAME" />

This works as when the DSP is loaded independantly, the page is redirected; though when it's embedded, the <head> is omitted and no redirect performed.

However, I did notice that webmessages put in the execute trigger would still be performed before the redirect enacted. Also, it appears uniface has no control over a redirect like this

Any ideas for something better and more secure?

How to stop direct access of a DSP?

Author: jason_zuvela@yahoo.com (jasonzuvela)

Hi

I want to embed a range of DSPs using DSP containers, but I don't want to allow users to access those embedded components directly. So they should only be accessible through a DSP container. Has anyone come up with a solution to stop someone from directly accessing a DSP (by typing the component id into the url)?

eg. http://server:port/uniface/wrd/COMPONENTNAME

I have tried looking into filtering urls in the http requests at a webserver level, through use of .htaccess or similar, but it doesn't seem like tomcat supports this kind of functionality. So far the only solution I have found is to put a http redirect in the DSP's <head>:

<meta http-equiv="Refresh" content="0; url=http://server:port/uniface/wrd/MAINCOMPONENTNAME" />

This works as when the DSP is loaded independantly, the page is redirected; though when it's embedded, the <head> is omitted and no redirect performed.

However, I did notice that webmessages put in the execute trigger would still be performed before the redirect enacted. Also, it appears uniface has no control over a redirect like this

Any ideas for something better and more secure?

Hello,

the simplest way to do this is to not include the scope "public web" in execute trigger.

 

If you need to access to this component directly, you have to manage right access to the dsp in the getState trigger.

If this trigger return the value -21, the WRD return an authorisation failure (see: Uniface Reference->Trigger Standard -> Get State).

 Regards,

Phlippe


Author: Philippe (philippe.grangeray@agfa.com)

How to stop direct access of a DSP?

Author: jason_zuvela@yahoo.com (jasonzuvela)

Hi

I want to embed a range of DSPs using DSP containers, but I don't want to allow users to access those embedded components directly. So they should only be accessible through a DSP container. Has anyone come up with a solution to stop someone from directly accessing a DSP (by typing the component id into the url)?

eg. http://server:port/uniface/wrd/COMPONENTNAME

I have tried looking into filtering urls in the http requests at a webserver level, through use of .htaccess or similar, but it doesn't seem like tomcat supports this kind of functionality. So far the only solution I have found is to put a http redirect in the DSP's <head>:

<meta http-equiv="Refresh" content="0; url=http://server:port/uniface/wrd/MAINCOMPONENTNAME" />

This works as when the DSP is loaded independantly, the page is redirected; though when it's embedded, the <head> is omitted and no redirect performed.

However, I did notice that webmessages put in the execute trigger would still be performed before the redirect enacted. Also, it appears uniface has no control over a redirect like this

Any ideas for something better and more secure?

Phlippe is right, but do realize that the Execute trigger is also fired by the DspContainer (that contains it) the first time it needs to show the DSP. So, this construction only works if you use another operation as part of a preloading construction, where you preload the contained DSP together with the main DSP. The MusicShop demonstrates such a construction. Check the Execute trigger of the main DSP being MUSICMAIN. That activates a set of operations of the contained DSPs.

Another way is to create a Web Output Filter Plug-in component. Using such a component, which is just a SVC component you build yourself, you can manipulate the returned HTML just before it is send back to the browser.

  • Theme: Web Applications --> Developing a Uniface Web Application with Static Server Pages --> Creating a Web Output Filter Plug-in
  • Integrating with other Technologies--> Gomez Actual Experience XF

Regards,
Gerton

 

 


Author: Gerton Leijdekker (gerton.leijdekker@uniface.com)
Terms & ConditionsAccessibility statement