I'm wondering if anyone else has experienced this App Studio issue and has resolved it.

When opening App Studio, with the correct credentials already stored in the Environment Properties, one is prompted to logon to the reporting server EDASERVE.

Issue one: the credentials are already saved in the Environment properties.

Issue two: Entering the "correct" credentials in the prompt, it results in "Failed to logon to WebFOCUS Reporting Server EDAERVE", BUT then loads the environment just fine.

Issue three: Canceling the login prompt, results a Error prompt that no credentials are entered, BUT then loads the environment just fine.

So the prompt doesn't look like it actually preventing anything... It just significantly delays the opening of App Studio and frustrates the user experience with App Studio and a reason we haven't used it over Dev. Studio.

We've been using WFRS security, and our Reporting Server is setup for LDAP authentication. It's been like that since 2007 when we implemented WebFOCUS.

This issue started happening App. Studio 8009 and then upgraded version 8105M that we've been on since January. This doesn't happen for Dev. Studio.

If anyone has any insight, I would greatly appreciate it. My cases with support haven't resulted in a resolution yet and hoping someone here might have ran across this.

Thanks,
Nate

This message has been edited. Last edited by: <Nate Conn>,

That nuisance pops up here too sometimes.

One of our workarounds is to rename the WFSCOM.XML file in the user's AppData/Roaming Directory.

After that it sometimes still claims incorrect credentials, but if you persist entering the correct credentials it will eventually save them and you should be good for a decent while again.

A similar issue that tends to accompany this one for us is that AS (or DS, they both have both issues) claims that our Reporting Server is not version 8 - which is a rather silly claim, as it is in fact 81M Gen 827. The solution appears to be the same.

Usually we're back in this mess when our Windows password expires and we have to change it. After that, it doesn't match the passwords that AS/DS stored, and it's time for a fresh game of whack-a-mole.

Thanks for your reply. I tried your workaround about a dozen times and it still annoyingly prompts even though I click the check box to remember my credentials. I'm guessing this isn't the same issue as yours as you mentioned your problem also happens for Dev. Studio in which ours does not.

Nate

The fact that is still works with dev studio but not app studio makes me believe it is a bug with app studio. You should open a case with techsupport and get their assistance. Make sure to tell them it does work with dev studio.

Chuck,

Thanks for the reply.

I would think so too, although using the latest AppStudio, as recommended by my case with TechSupport, results in the same issue and TechSupport mentioned no other customers have reported this issue. I imagine there are quite a few customers using App Studio by now and would be frustrated like myself and would have reported it by now. Looks like I'm the lucky one in experiencing this issue, but Tech Support cannot reproduce it.

Here's a session in the access.log that I captured at the opening of App. Studio...

- - [13/Dec/2017:15:12:46 -0500] "POST /ibi_apps/service/wf_security_check.jsp HTTP/1.1" 200 464
- - [13/Dec/2017:15:12:46 -0500] "POST /ibi_apps/WFServlet.ibfs HTTP/1.1" 302 -
- - [13/Dec/2017:15:12:48 -0500] "POST /ibi_apps/service/wf_security_check.jsp HTTP/1.1" 200 496
- - [13/Dec/2017:15:12:49 -0500] "POST /ibi_apps/WFServlet HTTP/1.1" 403 413

-- the line above is where I get prompted for EDASERVE

-- here's where I click OK with no credentials and it still lets me in

- - [13/Dec/2017:15:16:34 -0500] "POST /ibi_apps/service/wf_security_check.jsp HTTP/1.1" 200 496
- - [13/Dec/2017:15:16:35 -0500] "POST /ibi_apps/WFServlet.ibfs HTTP/1.1" 200 20618
- - [13/Dec/2017:15:16:35 -0500] "GET /ibi_apps/ibi_html/S172_14698234351F/javaassist/ibi/html/composer/wf_as_ready.bmp HTTP/1.1" 200 3126
- - [13/Dec/2017:15:16:36 -0500] "POST /ibi_apps/home HTTP/1.1" 200 830
- - [13/Dec/2017:15:16:36 -0500] "GET /ibi_apps/ibi_html/S172_14698234351F/javaassist/ibiapplets.txt HTTP/1.1" 200 149529
- - [13/Dec/2017:15:16:37 -0500] "POST /ibi_apps/WFServlet.ibfs HTTP/1.1" 200 20618
- - [13/Dec/2017:15:16:37 -0500] "POST /ibi_apps/WFServlet.ibfs HTTP/1.1" 200 438


Note, the 403 status. TechSupport is saying "/ibi_apps/WFServlet" are legacy calls (pre 8.x) and the "/ibi_apps/WFServlet.ibfs" ,that resolve successfully, are native 8.x calls. So now I'm wondering why there are legacy calls in my environment when my servers only started at the 8007 version.

Nate

What security group(s) are you part of? Can you access the security center and right mouse click on your id and choose Groups / Group Membership Report

Is your reporting server set to "trusted"?

We see this issue too. We are using integrated windows security so, in theory, we do not need to pass credentials.

However - we often get prompted for login username/password - I just hit logon - without supplying any credentials...often - after that - we see an "Unable to Log On - the operation timed out: myEnvironementName. I just wait patiently - and it opens fine after that.

It's irritating - but it does work so I have not logged a case about this as I consider it a minor irritant.

Hopefully a future release will iron it out.

We did try to log a case, a while back. However, we never managed to create a reproducible test case.

I don't think we were even sure we were always looking at the same issue. In some cases investigation turned up that there was a logical explanation, such as the previously mentioned password expiry policy, in other cases it did not.

This happens quite a lot in my setup.
I just have App Studio stand alone, not connecting to any external server, just the localhost server that comes with App Studio.
In my setup this happens only at the start of the day.
I think it has to do with not just App studio starting up, but also a lot of other stuff, which alwys happens when the machine wakes up. It is (I think) some sort of time out that occurs, especially at startup time.
Waiting a few minutes and then signing in again (or restarting App Studio) resolves the problem in almost all cases.

Chuck,

My user is part of the Administrators and Library_privilege groups.

Thanks,
Nate

quote:

Originally posted by Chuck Wolff:
Nate

What security group(s) are you part of? Can you access the security center and right mouse click on your id and choose Groups / Group Membership Report

Craig,

Our LDAP security on the reporting server has the accepts trusted connections option enabled.

In our Client Admin Console for the reporting server, EDASERVE is set to Default security, EDAMR (another node that points to the same reporting server that all MR domains are tied to) is to set to a service account security.

That's our TEST environment that IBI support suggested...our PROD environment that experiences the same issue is setup the same way except our LDAP security on the reporting server does not accept trusted connections and in the Admin Console on the client the EDAMR node has a profile that has a simple
HTTP_USER_AGENT NE "WFSCOM"

that sets the IBI_REPORT_USER and IBI_REPORT_PASS to the same service account as in our TEST environment.

Both environments exhibit the same issue.

Thanks,
Nate

quote:

Originally posted by Craig Thummel:
Is your reporting server set to "trusted"?

Hi Nate

My suggestion is on the admin console on the client side is to set the security to trusted and on the server side set the LDAP to accept trusted connections.

I used to be an systems engineer at IBI and used this successfully at all my customer sites.

Happens at our site too. In addition to these "features", we get errors running things from AppStudio as well. Sometimes, we can't even get into AppStudio until we restart the entire reporting server instance. Fun times! Have case(s) open.

So finally, the solution that works for us that was suggested from support is to change the configs to that below...

..\ibi\WebFOCUS80\config\securitysettings.xml

  
<property name="ConcurrentSessionFilterEnabled" value="false"/>

<property name="sessionAuthenticationStrategy" value=" SessionFixationProtectionStrategy "/>

stop and restart tomcat.


This is also mentioned in the 8.1.x upgrade considerations docs but it was not clear to me at the time that we needed this, as it only mentions it's needed for RESTful web services which I don't believe we use.


Nate

This message has been edited. Last edited by: <Nate Conn>,

Is there any documentation of these settings, especially the first of the two?

Our securitySettings.xml explicitly sets the first to "true", with the same setting for the second option. I seem to recall this is what IBI tech support advised us to use.

Without documentation it's very hard to edit that file (and apparently we're supposed to do so), as neither do we know what the options mean nor what possible values they might have (well, with the exception of the boolean values, I suppose).

Frankly, even if there is documentation for this one, I have no idea where to start looking.

I asked the same thing to support and they only came back with the known references in the 8.1.x Upgrade Consideration guides.

Not to mention you try to use their search and 9.9 times out of 10 you get nothing back, or get randomness that doesn't help.

Good luck!