Focal Point Banner


As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only.

Join the TIBCO Community
TIBCO Community is a collaborative space for users to share knowledge and support one another in making the best use of TIBCO products and services. There are several TIBCO WebFOCUS resources in the community.

  • From the Home page, select Predict: WebFOCUS to view articles, questions, and trending articles.
  • Select Products from the top navigation bar, scroll, and then select the TIBCO WebFOCUS product page to view product overview, articles, and discussions.
  • Request access to the private WebFOCUS User Group (login required) to network with fellow members.

Former myibi community members should have received an email on 8/3/22 to activate their user accounts to join the community. Check your Spam folder for the email. Please get in touch with us at community@tibco.com for further assistance. Reference the community FAQ to learn more about the community.


Focal Point    Focal Point Forums  Hop To Forum Categories  WebFOCUS/FOCUS Forum on Focal Point     MRE: Limit users to only dashboard?

Read-Only Read-Only Topic
Go
Search
Notify
Tools
MRE: Limit users to only dashboard?
 Login/Join
 
Gold member
posted
Greetings,

We have a mix of users in our MRE environment, some using MRE applet, and some that are deployed to only Dashboard group views (no tree). We would like to prevent the Dashboard-only users from logging on to the MRE via applet. Is there a way to do this?

Regards,

Dan Kenny
University of Nebraska at Omaha
Prod: WF 7.1.5 Test: WF 7.6.0
 
Posts: 63 | Registered: March 07, 2006Report This Post
<TSR123>
posted
Hi Dan,

Unfortunately, the Managed Reporting is the Dashboards Repository. All the Users, Groups and Domains get created in Managed Reporting. If a user has access to the Dashboard they will also have access to the Managed Reporting.

Please let me know if this answers your question.
Regards,
Monica
 
Report This Post
Platinum Member
posted Hide Post
Monica is right on the money Dan.
When we deployed BID after having MRE for a while before that, we had the same problem. Here is what we did to get around it ....

#1> We disabled the then-current MRE URL and all other internal self-serv app URLs (with a msg on some to contact the WF-Admin if they are still stuck on it).

#2> Defined a new MRE log-in page Alias that we shared only with the Power-user (developer) types that continued to have the MRE. Our security policies informed them NOT to share this URL with other users, but always contact the WF-Admins in such cases. (But ofcourse, we are still at their mercy as much as enforcing those security policies go).

#3> Deployed BID-GroupViews and distributed them to their respective users, who now use them instead of the old MRE or SSA links.

Not exactly fool-proof, but this methodology worked for us.

Gooooooooood luck with yours !!
Sandeep.


-------------------------------------------------------------------------------------------------
Blue Cross & Blue Shield of MS
WF.76-10 on (WS2003 + WebSphere) / EDA on z/OS + DB2 + MS-SQL
MRE, BID, Dev. Studio, Self-Service apps & a dash of fun !! Music
 
Posts: 218 | Location: Jackson, MS | Registered: October 31, 2006Report This Post
Gold member
posted Hide Post
Thanks for the responses and suggestions, it is much appreciated.

I was hoping to be able to differentiate the client access path (MR applet verses WORP) and lock them at the server level after authentication but I guess I'm stuck with just manipulating the login screen.

Sure would be nice to be able to tell if someone came in from which client, whether it was Dev Studio/MR Developer, MRE applet or Dashboard, and be able to lock access based on userid or group affiliation. Dashboard has some nice features for tailioring the interface to a domain (role-based and specific content block layouts), but it all is rather leaky from a security standpoint if users can poke around the domain via MRE applet.

Regards,

-- Dan

University of Nebraska at Omaha
Prod: WF 7.1.5 Linux Test: 7.6.0 Linux
 
Posts: 63 | Registered: March 07, 2006Report This Post
Platinum Member
posted Hide Post
That is a very good point Dan, one that is worthy of sending to IBI as a NFR.

It sure would be nice to be able to differentiate the User types.

Sandeep M.


-------------------------------------------------------------------------------------------------
Blue Cross & Blue Shield of MS
WF.76-10 on (WS2003 + WebSphere) / EDA on z/OS + DB2 + MS-SQL
MRE, BID, Dev. Studio, Self-Service apps & a dash of fun !! Music
 
Posts: 218 | Location: Jackson, MS | Registered: October 31, 2006Report This Post
Expert
posted Hide Post
There IS a way to tell where the user came from.

Read these postings:

https://forums.informationbuilders.com/eve/forums/a/tpc/...961093381#2961093381
https://forums.informationbuilders.com/eve/forums/a/tpc/...771034591#3771034591

They explain how to add HTTP Header Variables.

There's one called HTTP_REFERER, this gives you the URL of where the request was made from.

Once you set up this HTTP Header Variable, it becomes a Dialog Manager variable that can be accessed from any WebFOCUS program. You can add WebFOCUS code to edasprof.prf to verify where a user came from.

--

Reference: Check out the WebFOCUS Security and Administration manual. Look for "HTTP Header Variables Available for Script Processing".


Francis


Give me code, or give me retirement. In FOCUS since 1991

Production: WF 7.7.05M, Dev Studio, BID, MRE, WebSphere, DB2 / Test: WF 8.1.05M, App Studio, BI Portal, Report Caster, jQuery, HighCharts, Apache Tomcat, MS SQL Server
 
Posts: 10577 | Location: Toronto, Ontario, Canada | Registered: April 27, 2005Report This Post
Gold member
posted Hide Post
Thanks, Francis --

Those are very useful informational links, in more than just the present task. I will experiment with variables passing.

The biggest challenge with applying this approach is that we have many MRE applet users that ALSO use Dashboard group views. I do not relish the approach of having to hard-code userids into edasprof.prf in order to prevent the dashboard-only users from using MRE applet. This maintenance problem might be made less if I can lock onto their group names and hard-code those tests in edasprof.prf, but it all seems quite kludgy and maintenance-intensive.

It would be so much easier if we could have check boxes on each userid that included "applet" like we do for "advanced" and "schedule".

Regards,

Dan Kenny
University of Nebraska at Omaha
 
Posts: 63 | Registered: March 07, 2006Report This Post
Expert
posted Hide Post
Dan, I agree that managing the user's access rights through the MRE User Administration tool would be the best way.

Cheers,


Francis


Give me code, or give me retirement. In FOCUS since 1991

Production: WF 7.7.05M, Dev Studio, BID, MRE, WebSphere, DB2 / Test: WF 8.1.05M, App Studio, BI Portal, Report Caster, jQuery, HighCharts, Apache Tomcat, MS SQL Server
 
Posts: 10577 | Location: Toronto, Ontario, Canada | Registered: April 27, 2005Report This Post
  Powered by Social Strata  

Read-Only Read-Only Topic

Focal Point    Focal Point Forums  Hop To Forum Categories  WebFOCUS/FOCUS Forum on Focal Point     MRE: Limit users to only dashboard?

Copyright © 1996-2020 Information Builders