J2 is pleased to announce that we have now released NHaystack.
NHaystack is an open-source Niagara AX module that serves up Haystack data directly from a Niagara AX station, via a RESTful protocol. NHaystack is licensed under the Academic Free License ("AFL") v. 3.0.
not sure where to raise this question, so thought I'd ask it here first.
I'm using the nHaystack 1.2.3 on Niagara 3.8.38 so I can connect SkySpark haystack connector to it. It's working fine for me and certainly notice it's quite a bit faster than accessing over the obix connector.
But I've noticed today that when I configure the haystack connector in SkySpark with a username that I've configured to only be able to see the histories under a particular folder, I can still see all histories via the connector on that station in all folders.
We have a central supervisor station that we use to bring histories together from all our client sites. So each client's histories are stored on that station under a folder named after them. I then create a user in Niagara that can only see the histories in that folder. The client can then use that username and log into Periscope which is running on that central station.
Now that our clients are also going to be accessing SkySpark that we host for them, the project that they access in SkySpark should be using a connector configuration that can only see and access that client's histories.
nHaystack seems to ignore the ACL controls configured for the user.
Sorry for the long winded explanation. Hopefully it makes some sense.
Thanks
John
Mike JarmyWed 26 Nov 2014
This problem may have been introduced with some recent refactoring of the code that we did. We are investigating, and if we can reproduce the problem we will provide a patch ASAP.
John MacEnriWed 26 Nov 2014
Thanks Mike. Look forward to hearing from you.
Regards
John
Mike JarmyWed 26 Nov 2014
I can confirm that this problem is reproducible. We have a fix in the works.
We will release as soon as we have a chance to do some testing on it, which will probably be Monday, since the rest of this week is a holiday in the US.
Mike JarmyTue 2 Dec 2014
We have created a fix for this, but we are doing some additional testing now to make sure we found everything. We will post a patch as soon as we are confident that it is correct.
Mike Jarmy Tue 30 Apr 2013
J2 is pleased to announce that we have now released NHaystack.
NHaystack is an open-source Niagara AX module that serves up Haystack data directly from a Niagara AX station, via a RESTful protocol. NHaystack is licensed under the Academic Free License ("AFL") v. 3.0.
NHaystack is available at https://bitbucket.org/jasondbriggs/nhaystack
John MacEnri Tue 25 Nov 2014
Hi,
not sure where to raise this question, so thought I'd ask it here first.
I'm using the nHaystack 1.2.3 on Niagara 3.8.38 so I can connect SkySpark haystack connector to it. It's working fine for me and certainly notice it's quite a bit faster than accessing over the obix connector.
But I've noticed today that when I configure the haystack connector in SkySpark with a username that I've configured to only be able to see the histories under a particular folder, I can still see all histories via the connector on that station in all folders.
We have a central supervisor station that we use to bring histories together from all our client sites. So each client's histories are stored on that station under a folder named after them. I then create a user in Niagara that can only see the histories in that folder. The client can then use that username and log into Periscope which is running on that central station.
Now that our clients are also going to be accessing SkySpark that we host for them, the project that they access in SkySpark should be using a connector configuration that can only see and access that client's histories.
nHaystack seems to ignore the ACL controls configured for the user.
Sorry for the long winded explanation. Hopefully it makes some sense.
Thanks
John
Mike Jarmy Wed 26 Nov 2014
This problem may have been introduced with some recent refactoring of the code that we did. We are investigating, and if we can reproduce the problem we will provide a patch ASAP.
John MacEnri Wed 26 Nov 2014
Thanks Mike. Look forward to hearing from you.
Regards
John
Mike Jarmy Wed 26 Nov 2014
I can confirm that this problem is reproducible. We have a fix in the works.
We will release as soon as we have a chance to do some testing on it, which will probably be Monday, since the rest of this week is a holiday in the US.
Mike Jarmy Tue 2 Dec 2014
We have created a fix for this, but we are doing some additional testing now to make sure we found everything. We will post a patch as soon as we are confident that it is correct.