Section Access: Both USERID & NTNAME

[Anonymous]

Hi

Is it viable with Section Access to use both the USERID & NTNAME methods in a single qvw ?

Best Regards,     Bill

[hic]

Yes. A correct match in both will be demanded in order to open the file.

HIC

[Anonymous]

Henric

Thanks for confirming that.

Back to the drawing board for me then.  It must be something else causing me problems.

Many Thanks,     Bill

[hic]

No using Upper case, perhaps?

[Anonymous]

Henric

I was discussing this with Steve Dark earlier today.  He noticed that the Section Access data was being loaded from resident as per the script below.  [I was doing this for diagnostics so that I could show on the dashboard the Section Access data].

///////////////////////////////////////////////////////////////////////////

SectionAccessData :

///////////////////////////////////////////////////////////////////////////

LOAD *

INLINE [

  ACCESS, USERID, PASSWORD, BU, NTNAME

  ADMIN, ADMIN, ADMIN,  ALL , *

  ADMIN, *, *, ALL, EMEA\ADUSER01

  USER, *, *, BHX, EMEA\ADUSER02

  USER, *, *, BHX, EMEA\ADUSER03

  USER, BFS,BFS, BFS, *

  ADMIN, BHD,BHD, BHD, *

  USER, BHX,BHX,BHX, *

  USER, BRSGH,BRSGH, BRSGH, *

];

///////////////////////////////////////////////////////////////////////////

///////////////////////////////////////////////////////////////////////////

Section Access;

///////////////////////////////////////////////////////////////////////////

LOAD * resident SectionAccessData ;

///////////////////////////////////////////////////////////////////////////

Section Application;

///////////////////////////////////////////////////////////////////////////

This all works fine when tested using the QV Desktop.  But when accessed via QV Server using the Ajax client with AD USER EMEA\ADUSER01 then it prompts for a Userid & Password and none of the values set in the Section Access are accepted as valid.

EDIT:     However if I untick Strict Exclusion then all works ok in Ajax Client as well as QV Desktop.

Steve suggested getting rid of the resident load resulting in this script.

///////////////////////////////////////////////////////////////////////////

Section Access;

///////////////////////////////////////////////////////////////////////////

LOAD * INLINE [

  ACCESS, USERID, PASSWORD, BU, NTNAME

  ADMIN, ADMIN, ADMIN,  ALL , *

  ADMIN, *, *, ALL, EMEA\ADUSER01

  USER, *, *, BHX, EMEA\ADUSER02

  USER, *, *, BHX, EMEA\ADUSER03

  USER, BFS,BFS, BFS, *

  ADMIN, BHD,BHD, BHD, *

  USER, BHX,BHX,BHX, *

  USER, BRSGH,BRSGH, BRSGH, *

];

///////////////////////////////////////////////////////////////////////////

Section Application;

///////////////////////////////////////////////////////////////////////////

This, I am glad to say, then worked perfectly via QV Server using the Ajax client with AD USER EMEA\ADUSER01, [as well as all still ok via the QV Desktop].

Could you shed any light on this ?

Best Regards,     Bill

[stevedark]

Just to add a bit more detail to what Bill has put here, I suggested moving the in-line directly into the Section Access part of the code as I had seen some strangeness previously - but equally I have seen it working fine where the table was built before the Section Access part and then is brought in with a RESIDENT load.

After proving that Section Access worked fine when the INLINE was in the Section Access part of the code we also reverted to how the code was previously and added an extra dummy column to the first SectionAccessData table - to ensure that the RESIDENT did not auto concatenate onto that table.  I have seen it where the Section Access table has auto concatenated onto a temporary table then appears to be dropped when the temporary table is removed.

A couple of other things that I noticed about Bill's sandbox app.  He has the BU column in the Section Access table ahead of the NTNAME column.  Also, on a tab previous to the Section Access one he loads a temporary table, PEEKs a value from it and then drops it.

I would always load Section Access columns in the order the Wizard does them (for consistency more than anything) and I would always make it the first table loaded (unless I needed to some JOINs to get the Section Access table built).  I don't know if either of those things could have a bearing on the problems Bill is seeing.

The difference in behaviour with the Strict Exclusion flag intrigues me here also.

Cheers,

Steve

[hic · Accepted solution]

Strange... Could be a bug. How do you authenticate yourself towards the QV Server? Is the Accesspoint running inside the domain?

I would open a support case on this. The Support guys are a lot better than me in figuring out authentication problems.

HIC

[Anonymous]

Henric

In answer to your questions :

     a)     Authentication towards the QV Server is via Microsoft Active Directory [AD] credentials.

     b)     QV AccessPoint is running within our EMEA domain [i.e. the same domain as the AD Users]

I'll raise a support case with QlikTech.

Many Thanks,     Bill

[Anonymous]

Hi

I have raised a Support Case with QlikTech, reference details :

     00234633 - Section Access - Resident Load [ ref:_00D20IGPX._500D0Z8any:ref ]

Best Regards,     Bill

[natebrunner]

Any answer or more insight on this? We are seeing similar issues.