Missing subdomain in /auth/registrar/access
Hinnerk Bruegmann
last time I inquired about the directories in use (/wsf/ws/ vs, /ws/ )
this time my question concerns the actual domain name handling.
In particular I am wondering if the domain name of the drupal
installation is somehow used by conStruct when concatenating URI
strings.
The log accessible at
http://consense-project.com/tools/logfiles?logname=structswf_test7.log
shows the SPARQL calls issued by structWSF when creating a new dataset
in conStruct (sorted chronologically bottom to top).
My drupal installation lies at http://consense-project.com
the structWSF installation at http://structwsf.consense-project.com
As you can see structWSF inserts the new dataset
http://structwsf.consense-project.com/wsf/datasets/85/ and sets
initial access rights for dataset http://structwsf.consense-project.com/wsf/datasets/85/
to 131.188.219.99 (IP of my server) and 0.0.0.0. So far so good.
Then 3 seperate calls to /ws/auth/registrar/access/ are made
apparently "refreshing" the access rights for the two ip's mentioned
above as well as newly setting them for my local client IP
84.148.61.237.
Strangely the URL of the dataset is in these cases
http://consense-project.com/wsf/datasets/85/ (note the missing
subdomain).
This means my local client is never granted access to the dataset
http://structwsf.consense-project.com/wsf/datasets/85/ (with
subdomain) which in turn means any query to /ws/dataset/read/?
uri=all®istered_ip=84.148.61.237 returns an empty dataset apart
from the default namespaces (as the /dataset/read/ query doesn't match
due to lacking permission triples).
Nowhere in data.ini or network.ini nor in the drupal config did I set
the address http://consense-project.com/ without the structwsf
subdomain. Do you have an idea where /auth/registrar/access/ gets this
wrong dataset URI?
Thank you a bunch,
Hinnerk
Frederick Giasson
> Hi again Fred,
>
> last time I inquired about the directories in use (/wsf/ws/ vs, /ws/ )
> this time my question concerns the actual domain name handling.
Good
> In particular I am wondering if the domain name of the drupal
> installation is somehow used by conStruct when concatenating URI
> strings.
Yes it could. One that we should always keep in mind:
conStruct is a user interface above structWSF. Multiple conStruct
instances can interact with a single structWSF instance. Something else
than conStruct can use a structWSF instance as well (think about the
Semantic Components for example).
This said, when you create something using a conStruct instance, some
tools (such as structCreate) will use its domain name to create the
URIs. That way, we make sure that the records created by a conStruct
instance will be dereferencable on the web.
Lets take a look at your stuff below:
> The log accessible at
> http://consense-project.com/tools/logfiles?logname=structswf_test7.log
> shows the SPARQL calls issued by structWSF when creating a new dataset
> in conStruct (sorted chronologically bottom to top).
I like this viewer. Is it using the internal log table, or you generated
the log files using another method?
> My drupal installation lies at http://consense-project.com
> the structWSF installation at http://structwsf.consense-project.com
Seems good.
> As you can see structWSF inserts the new dataset
> http://structwsf.consense-project.com/wsf/datasets/85/ and sets
> initial access rights for dataset http://structwsf.consense-project.com/wsf/datasets/85/
> to 131.188.219.99 (IP of my server) and 0.0.0.0. So far so good.
Good
> Then 3 seperate calls to /ws/auth/registrar/access/ are made
> apparently "refreshing" the access rights for the two ip's mentioned
> above as well as newly setting them for my local client IP
> 84.148.61.237.
> Strangely the URL of the dataset is in these cases
> http://consense-project.com/wsf/datasets/85/ (note the missing
> subdomain).
Yeah, apparently some missconfiguration somewhere.
My first question is: what does send these queries (I presume
conStruct?) Please outline the steps (UI navigation steps in conStruct
if it is what you did).
Also, please add the content of the data.ini and network.ini files to
this email (or send them to me by email if you don't want them publicly
available)
> This means my local client is never granted access to the dataset
> http://structwsf.consense-project.com/wsf/datasets/85/ (with
> subdomain) which in turn means any query to /ws/dataset/read/?
Given these queries, exact.
> uri=all®istered_ip=84.148.61.237 returns an empty dataset apart
> from the default namespaces (as the /dataset/read/ query doesn't match
> due to lacking permission triples).
>
> Nowhere in data.ini or network.ini nor in the drupal config did I set
> the address http://consense-project.com/ without the structwsf
> subdomain. Do you have an idea where /auth/registrar/access/ gets this
> wrong dataset URI?
Will need to debug, but the first thing I need is to know the steps that
created these queries.
Thanks!
Fred
Hinnerk Brügmann
> > The log accessible at
> > http://consense-
> project.com/tools/logfiles?logname=structswf_test7.log
> > shows the SPARQL calls issued by structWSF when creating a new
> dataset
> > in conStruct (sorted chronologically bottom to top).
> I like this viewer. Is it using the internal log table, or you
> generated
> the log files using another method?
>
The entries are generated at the sending, not the recieving end.
I added a couple error_log() php calls in the structWSF webservice files but
assure you no original functionality was touched at all so I feel confident
this can't be cause for the current issue.
Some quickly patched together php code is parsing and displaying the apache
logfile in Drupal - if you want I can gladly share that but it's no rocket
science code anyway. Just found it too cumbersome to track changes structWSF
did to virtuoso by querying virtuoso itself.
> > Then 3 seperate calls to /ws/auth/registrar/access/ are made
> > apparently "refreshing" the access rights for the two ip's mentioned
> > above as well as newly setting them for my local client IP
> > 84.148.61.237.
> > Strangely the URL of the dataset is in these cases
> > http://consense-project.com/wsf/datasets/85/ (note the missing
> > subdomain).
> Yeah, apparently some missconfiguration somewhere.
>
> My first question is: what does send these queries (I presume
> conStruct?) Please outline the steps (UI navigation steps in conStruct
> if it is what you did).
Yes construct.
After logging into Drupal and making sure my IP was registered with drupal
construct module (admin/settings/conStruct/access/) I would use
node/add/dataset in Drupal with settings
Default role member: <default>
Title: Test Dataset 7
Description: some description
WSF address: structwsf.consense-project.com
Existing Dataset URI: empty
Rest of the page no changes.
Btw - the setting "domain name to resolve resources" in
admin/settings/conStruct/ is set to:
structwsf.consense-project.com
Result of the creation would be:
* Dataset Test Dataset 8 has been created.
* No posts in this group.
WSF address:
structwsf.consense-project.com
This generated the log I posted in my last mail
> Also, please add the content of the data.ini and network.ini files to
> this email (or send them to me by email if you don't want them publicly
> available)
The password for virtuoso is xx'd out but works in the original file.
> Thanks!
> Fred
No - thank you!
Frederick Giasson
> The entries are generated at the sending, not the recieving end.
> I added a couple error_log() php calls in the structWSF webservice files but
> assure you no original functionality was touched at all so I feel confident
> this can't be cause for the current issue.
> Some quickly patched together php code is parsing and displaying the apache
> logfile in Drupal - if you want I can gladly share that but it's no rocket
> science code anyway. Just found it too cumbersome to track changes structWSF
> did to virtuoso by querying virtuoso itself.
You are talking about the log table, right?
Ok so, apparently that you found an inconsistency in the code that has
been discovered because you setuped a different base domain name in the
conStruct settings than the one of the construct node :)
The value of this setting is the Drupal variable called
"conStruct_UrisDomain" available in the "variables" table of your Drupal
installation.
However, if you look at the conStruct.module file, it is where the
accessed, using AuthRegistrar, are created. The problem is that the code
in there used the $base_url and doesn't look at the conStruct_UrisDomain
variable. So, it is why you end-up with this inconsistency!
For my defense, I will say that this code is quite old, and that the
conStruct_UrisDomain variable came after :)
Here is the fix to your problem:
http://drupal.org/cvs?commit=454938
Please confirm that this fixes your current issue.
Thanks!
Take care,
Fred
Frederick Giasson
You are not sleeping? :) Looking at your new logs, apparently that it is
now working.
However, notice that the default IP (0.0.0.0) has CRUD
False;False;False;False by default. If you want to make it World
Readable, then you will have to update the permission of that user using
conStruct's UI (check the dataset tool and update the permissions from
there).
Note that I have an article on the tech wiki that talks about the
interaction between conStruct and structwsf, but it is currently
restricted (you can't see it) because it is not yet done. I will have to
work some more on it, I have the feeling that it may help a few person :)
Thanks,
Fred
Hinnerk Brügmann
> > The entries are generated at the sending, not the recieving end.
> > I added a couple error_log() php calls in the structWSF webservice
> files but
> > assure you no original functionality was touched at all so I feel
> confident
> > this can't be cause for the current issue.
> > Some quickly patched together php code is parsing and displaying the
> apache
> > logfile in Drupal - if you want I can gladly share that but it's no
> rocket
> > science code anyway. Just found it too cumbersome to track changes
> structWSF
> > did to virtuoso by querying virtuoso itself.
> You are talking about the log table, right?
To be honest - no.
I wasnt aware structWSF did it's own logging inside the Drupal database.
So what I linked was really custom error_log() calls from within structWSF
webservice code files (dirtily inserted into your code) writing out to the
subdomain's apache logfile.
> Ok so, apparently that you found an inconsistency in the code that has
> been discovered because you setuped a different base domain name in the
> conStruct settings than the one of the construct node :)
>
> The value of this setting is the Drupal variable called
> "conStruct_UrisDomain" available in the "variables" table of your
> Drupal
> installation.
>
> However, if you look at the conStruct.module file, it is where the
> accessed, using AuthRegistrar, are created. The problem is that the
> code
> in there used the $base_url and doesn't look at the
> conStruct_UrisDomain
> variable. So, it is why you end-up with this inconsistency!
>
> For my defense, I will say that this code is quite old, and that the
> conStruct_UrisDomain variable came after :)
>
> Here is the fix to your problem:
>
> http://drupal.org/cvs?commit=454938
>
> Please confirm that this fixes your current issue.
I can gladly confirm that - great!
Thank you yet again for your amazingly helpful assistance :-)
> You are not sleeping? :) Looking at your new logs, apparently that it
> is
> now working.
Sleep is for the wicked :-)
> However, notice that the default IP (0.0.0.0) has CRUD
> False;False;False;False by default. If you want to make it World
> Readable, then you will have to update the permission of that user
> using
> conStruct's UI (check the dataset tool and update the permissions from
> there).
My "business case" is related to personal documents (MS Word files etc) and
their semantic relation to each other so is not that I want to publish
semantic data in the sense of OpenLinkedData at the moment - more Semantic
Network in contrast to Semantic Web. Therefore pushing things out to the
world isn’t really a high priority here.
This is one of the reasons why I felt so compelled by your framework as it
has inherent permission management in contrast to some other open source
solutions I came across.
Anyway - hopefully I will soon come to a stage where I can actually
contribute instead of just "leech" help.
Cheers and thanks again,
Hinnerk
Frederick Giasson
> To be honest - no.
> I wasnt aware structWSF did it's own logging inside the Drupal database.
> So what I linked was really custom error_log() calls from within structWSF
> webservice code files (dirtily inserted into your code) writing out to the
> subdomain's apache logfile.
Well, you may like to take a look at it, it could helps you generating
even better outputs :) (one thing that is missing for example, are the
parameters).
I can tell you where it is (but you should know if you setuped it in the
process).
>> Ok so, apparently that you found an inconsistency in the code that has
>> been discovered because you setuped a different base domain name in the
>> conStruct settings than the one of the construct node :)
>>
>> The value of this setting is the Drupal variable called
>> "conStruct_UrisDomain" available in the "variables" table of your
>> Drupal
>> installation.
>>
>> However, if you look at the conStruct.module file, it is where the
>> accessed, using AuthRegistrar, are created. The problem is that the
>> code
>> in there used the $base_url and doesn't look at the
>> conStruct_UrisDomain
>> variable. So, it is why you end-up with this inconsistency!
>>
>> For my defense, I will say that this code is quite old, and that the
>> conStruct_UrisDomain variable came after :)
>>
>> Here is the fix to your problem:
>>
>> http://drupal.org/cvs?commit=454938
>>
>> Please confirm that this fixes your current issue.
> I can gladly confirm that - great!
> Thank you yet again for your amazingly helpful assistance :-)
Well my pleasure. Thanks for reporting edge case issues :)
>> You are not sleeping? :) Looking at your new logs, apparently that it
>> is
>> now working.
> Sleep is for the wicked :-)
Hahahah, good :)
>> However, notice that the default IP (0.0.0.0) has CRUD
>> False;False;False;False by default. If you want to make it World
>> Readable, then you will have to update the permission of that user
>> using
>> conStruct's UI (check the dataset tool and update the permissions from
>> there).
> My "business case" is related to personal documents (MS Word files etc) and
> their semantic relation to each other so is not that I want to publish
> semantic data in the sense of OpenLinkedData at the moment - more Semantic
> Network in contrast to Semantic Web. Therefore pushing things out to the
> world isn�t really a high priority here.
Good
> This is one of the reasons why I felt so compelled by your framework as it
> has inherent permission management in contrast to some other open source
> solutions I came across.
Great. Well, it is once you understood the underlying principles and
methods you have to use to make it work. But once the beast is daunted,
we (I as the developer) are finding that this framework helps us
implementing the projects (data related) of ours clients much faster
than it would have been possible for us 2 years ago (before starting to
develop this framework).
If you are reading my blog, you are probably already aware of a few
successful implementations.
> Anyway - hopefully I will soon come to a stage where I can actually
> contribute instead of just "leech" help.
Great! Well, I am always looking for help :)
I think your next step is to check how to import/create/update data into
this structWSF instance (via conStruct or not).
You may want to take a look at the Instance Record Forms Format to
create the templates for the Create/Update user interface [1]
Also you may want to start looking at the templating system to display
information about your records [2]
Naturally, depending if you want to access them via conStruct or not.
[1] http://techwiki.openstructs.org/index.php/Instance_Record_Forms_Format
[2] http://techwiki.openstructs.org/index.php/Building_conStruct_Templates
Take care,
Fred