NetTalk Central

Author Topic: Restrictok issue  (Read 339 times)

wasatchconsulting

  • Jr. Member
  • **
  • Posts: 75
    • View Profile
    • Email
Restrictok issue
« on: May 20, 2026, 11:00:22 AM »
I am running NetTalk 14.37 and Secwin 7.6

I have a procedure that was generated called on a webserver project called SecWinLoginWeb. I have had no issues for years and then just recently, the login page stopped appearing on the main page. I can still just type in the procedure and the login page appears and I can login and move forward.

I set some trace up and everything is just fine with GetSessionLoggedIn() and CanCall(), but RestrictOk() is giving a response of "1" and not "0" and so the button does not appear. All other buttons appear without any issues with the logic used.

I tried even bringing in a login page from another application just to see if there is something about the procedure, but there is something else that is giving the wrong response. I don't see any clues as to what RestrictOK() is looking at and the documentation does not mention this procedure.

Any assistance would be greatly appreciated

Ken Watts

seanh

  • Full Member
  • ***
  • Posts: 101
    • View Profile
    • Email
Re: Restrictok issue
« Reply #1 on: May 20, 2026, 03:41:03 PM »
This similar to a situation I had with the logout menu item.
I added this code to webhander procedure in webhandler.p_web,   restrictok method,  Priority 3000
        if pProcedure = 'SecwinLogoutWeb'   !smh Hack to get logout ok
            ReturnValue = sw:CanAccess
        END
It's just after a call to SecwinCurrentUser.getRight

I could never trace why it was coming back restricted when I set everything otherwise.
I also have secwin set to deny by default, which I think was part of the problem.

wasatchconsulting

  • Jr. Member
  • **
  • Posts: 75
    • View Profile
    • Email
Re: Restrictok issue
« Reply #2 on: May 21, 2026, 11:38:49 AM »
Well that workaround worked. Same as you, I cannot figure out why it is returning restricted as I cannot figure out what it was looking at. Maybe CanCall is what needs to be reviewed.

Thanks for the workaround.

Ken