You are viewing limited content. For full access, please sign in.

Discussion

Discussion

BUG: Custom URL Consuming All Read-only Licenses (?id=)

posted on January 24, 2019 Show version history

Due to an ongoing issue with IE 11.x not being able to properly redirect with the latest WebLink 10.x style URLs we had to customize the URL so that it would work across all browsers.

Original:

https://ourserver/WebLink/Browse.aspx?id=183288&dbid=0&repo=OurRepository

 

Customized:

https://ourserver/WebLink/Browse.aspx?id=183288

 

While this customized URL worked great we started noticing all of our read-only licenses being used up. We quickly figured out it was the customized URL doing this by setting up a test that had 10 unique customized links while having only one person click on each one. Every click on the link consumed 1 license.

We are still unable to figure out why not all browsers can use the default URL style of https://ourserver/WebLink/Browse.aspx?id=183288&dbid=0&repo=OurRepository

UPDATE:

Would like to add that this isn’t unique to our installation as this can bring any WebLink 10.x site down with limited licenses and auto-login activated.

0 0
replied on May 6, 2019

We just upgraded to Weblink 10 today and are having the same issue. Have you discovered any reason that this was happening? Any suggestions with how to fix this from happening?

 

Thanks.

0 0
replied on January 24, 2019

You probably know that ASP.Net sessions are defined by a session cookie.  Does the WL server not set that, or is the browser not returning it?  Or is it dropped by whatever mechanism is supplying your custom url?

0 0
replied on January 25, 2019

Brian,

It's maintaing the same session cookie value but consuming a new license with every hit. The only cookie that is receiving a new value is the lastSessionAccess one.

0 0
replied on January 24, 2019

Can you be more specific about the original problem? What isn't working in IE?

0 0
replied on January 25, 2019 Show version history

Devin,

When those using IE 11.x on Windows 7 or Windows 10 (Also Chrome / Compatibility View is turned off) would visit WebLink using the URL style of https://ourserver/WebLink/Browse.aspx?id=183288&dbid=0&repo=OurRepository they would experience a significant delay or it would route to the main root directory of our repository. However, once we shortened it down to the style of https://ourserver/WebLink/Browse.aspx?id=183288 they would be taken to the intended folder or file with no issues.

I didn't get to technical about the issue yet because I am not sure if it's something on our internal network causing this but the issue didn't start until we upgraded from WebLink 9.x to 10.x so we are still investigating it.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.