LDAP: username with special characters
Mikaël Naveau
I'm currently installing a XNAT server and I have a question regarding the LDAP authentication. I authenticate the users using the sAMAccountName field of the LDAP server. Unfortunately this name usually contain a dot that XNAT seems to not appreciate!
The authentication works fine, but everything related to a research in the database failed. Considering the error paste below, I guess that's because of the tables created in the xdat_search schema:
org.postgresql.util.PSQLException: ERROR: cross-database references are not implemented: "xdat_search._m.naveau_1414071787792"
My question is: what would be the best workaround to solve the problem? I can imagine different solutions but I would really appreciate some hints:
- Use another field of the LDAP to authenticate the users: there is no other unique field without special characters...
- Modify the name of the user after the authentication
- Remove the special characters of the username for all SQL request
- ...
Regards,
Mikael
McKay, Michael
Mikael,
I think the best solution would be for us to fix the XNAT code so that if the LDAP username contains characters that XNAT doesn’t like to see in usernames, they get replaced by characters that XNAT permits. We already have it set up so that if the username for an LDAP account matches the username of an existing XNAT account, that LDAP user gets assigned an XNAT username equal to their LDAP username with a number appended to it to make it unique. I am currently working on a fix so that problematic characters also get replaced at the same time. I’ll have this fix done today or tomorrow and it should be included in XNAT 1.6.4 which will be released any day now. Would it be possible for you to upgrade your instance of XNAT to 1.6.4?
-Mike
--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
xnat_discussi...@googlegroups.com.
To post to this group, send email to
xnat_di...@googlegroups.com.
Visit this group at http://groups.google.com/group/xnat_discussion.
For more options, visit https://groups.google.com/d/optout.
The material in this message is private and may contain Protected Healthcare Information (PHI). If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.
Mikaël Naveau
Yes, I can upgrade to the next version (or reinstall everything from scratch).
Many thanks for your help! I already had a look at the XnatLdapAuthenticator but I'm afraid that one small modification will have disastrous side effect!
Let me know if I can help for testing or anything else.
All the best,
Mikael
McKay, Michael
Mikael,
Sorry for the delay in getting back to you. I have a fix which should resolve your problem, but we unfortunately do not have any Active Directory users with special characters in their usernames, so until we get a test Active Directory set up, I will be unable to verify that my fix did in fact properly resolve your issue. This might not happen anytime soon, but if you’re willing to test it out yourself, that would be much appreciated. You’ll want to install XNAT using the latest code from https://bitbucket.org/nrg/xnat_builder_1_6dev (see https://wiki.xnat.org/display/XNAT16/Build+XNAT+from+Source+Repository if you want more information on how to do this). Please let me know whether that fix works for you and whether there’s anything else I can help you with.
And Mark,
XNAT does not alter password inputs. We pass everything verbatim to the authentication mechanism. After authentication, XNAT tries to create an XNAT account for that user if one does not already exist. If their AD username would not be a valid XNAT username (either because a user with that username already exists, or, as of my latest fix, because of special characters in the username), the user will be assigned a username as close as possible to their AD username.
Mikaël Naveau
Thanks for your update.
I installed a the latest version with your patch:
- The authentication with the LDAP server still works well
- The admin receives a mail to enable the account (The username does not contain any special characters anymore)
- The problem is that even if the account is enabled, the user can't connect to the webapp:
- after the authentication, the app redirects to the page which explain that an admin has to enable the account
- the admin receive the "new user" mail once again.
- the authentication is marked as failed in the access.log :
2014-11-02 20:31:53,724 - m.naveau 127.0.0.1 Authentication FAILED
I observed the same behavior even if I check the "Auto-enable User Accounts?" in the configuration panel of XNAT.
Any idea?
All the best,
Mikael
Mikael
McKay, Michael
Mikael,
Thank you so much for testing this! I was able to track down the cause and the problem was that there was one place we were referring to the LDAP username when we should have been referring to the XNAT username. This was causing our code to handle LDAP usernames which matched existing XNAT database usernames to fail, as well as my new code to address the special characters issue you ran into. We still don’t have any LDAP usernames with special characters to test with, so I can’t guarantee that everything will work now, but I’m optimistic that it will if you use the latest code from https://bitbucket.org/nrg/xnat_builder_1_6dev (including my change from an hour ago). You should be able to log in with your existing LDAP username and password. It will just map to an XNAT username that has the special characters replaced by underscores. Please let me know whether this resolves your issue and whether there’s anything else I can help with.
Mikaël Naveau
Thank you for your fix. I quickly tested the new version and everything is working fine with the LDAP authentication. I will reinstall XNAT on our server, run a larger test with the users and let you know if we have any issue.
Another side question: do you think that the current development version is mature enough to be installed for production? Considering that you're close to the 1.6.4 release, I'm wondering if the upgrade will be straight forward or if we should expect lots of effort for the migration ;-p
All the best,
Mikael
Mikaël Naveau
Here is some results about the tests I ran today:
First the good news!
- Authentication using LDAP works fine and replace the special characters by an underscore
- User can create their own project and the sql statement doesn't failed anymore
- I didn't notice any trouble related to the DicomReceiver, data are correctly assign to the corresponding user project and archive accordingly
Now some issues I got, but maybe not related to your fix:
- At the start of the tomcat server, this exceptions are thrown:
[localhost-startStop-1] ERROR xft.ItemWrapper -
org.nrg.xft.exception.ElementNotFoundException: Element not found: 'xdat:user'
at org.nrg.xft.meta.XFTMetaManager.FindElement(XFTMetaManager.java:219)
at org.nrg.xft.meta.XFTMetaManager.GetWrappedElementByName(XFTMetaManager.java:363)
at org.nrg.xft.schema.Wrappers.GenericWrapper.GenericWrapperElement.GetElement(GenericWrapperElement.java:163)
at org.nrg.xft.XFTItem.NewItem(XFTItem.java:203)
at org.nrg.xft.ItemWrapper.getItem(ItemWrapper.java:223)
at org.nrg.xdat.base.BaseElement.readExternal(BaseElement.java:449)
at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1837)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1796)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1990)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1915)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
at org.apache.catalina.session.StandardSession.readObject(StandardSession.java:1595)
at org.apache.catalina.session.StandardSession.readObjectData(StandardSession.java:1060)
at org.apache.catalina.session.StandardManager.doLoad(StandardManager.java:282)
at org.apache.catalina.session.StandardManager.load(StandardManager.java:202)
at org.apache.catalina.session.StandardManager.startInternal(StandardManager.java:489)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5476)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632)
at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1229)
at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1875)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)Nov 04, 2014 2:53:48 PM org.apache.catalina.session.StandardManager startInternal
SEVERE: Exception loading sessions from persistent storage
java.lang.NullPointerException
at org.nrg.xft.ItemWrapper.getItem(ItemWrapper.java:229)
at org.nrg.xdat.base.BaseElement.readExternal(BaseElement.java:449)
at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1837)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1796)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1990)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1915)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1990)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1915)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
at org.apache.catalina.session.StandardSession.readObject(StandardSession.java:1595)
at org.apache.catalina.session.StandardSession.readObjectData(StandardSession.java:1060)
at org.apache.catalina.session.StandardManager.doLoad(StandardManager.java:282)
at org.apache.catalina.session.StandardManager.load(StandardManager.java:202)
at org.apache.catalina.session.StandardManager.startInternal(StandardManager.java:489)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5476)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632)
at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1229)
at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1875)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
- the applet to upload images doesn't work, the web interface popup this messages:
ERROR : Failed to render project list: TypeError: this.projectResultSet is undefined
ERROR 200: Failed to parse project list.I hope that helps, please let me know if you need more informations/logs/tests.
Mikael
McKay, Michael
Mikael,
I’m glad to hear the authentication is now working for you. These other errors may be the result of it not setting up your site URL properly. What is the value of xdat.url in your build.properties file? Does it include a /xnat and is there a / at the end? For reference, on my local xnat instance the value of xdat.url is http://localhost:8080/xnat . You may find this discussion helpful to your situation: https://groups.google.com/forum/#!msg/xnat_discussion/kGrXf3_4FMA/R_sR3Pl3ofEJ .
And to answer your side question, we are getting very close to release to certifying it as production ready, and just need final sign-off from our test team. I expect that if there are any last-minute fixes that get in to 1.6.4, they will be small enough that you can easily update your instance of XNAT to include them. I think the chances are low that there would be major problems with using the current development tip on production, but it all depends on how risk-averse you are.
Let me know if there’s anything else I can help with!
Mikaël Naveau
As mentioned in the discussion you linked, the creation of a new user in the database (not using LDAP this time) solve the problem at the tomcat startup. I also double check that xnat is not configured as the root application in tomcat.
However, I still have an error when I try to upload images using the web interface.
Access: https://nmrxnat.ime.kfa-juelich.de:8443/xnat/app/template/LaunchUploadApplet.vm
First popup:
ERROR : Failed to render project list: TypeError: this.projectResultSet is undefinedERROR 200: Failed to parse project list.- I checked that the xdat.url is right in the build.properties (xdat.url=https://nmrxnat.ime.kfa-juelich.de:8443/xnat)
- two discussions already mentioned this problem (in 2009):
- https://groups.google.com/forum/#!searchin/xnat_discussion/Failed$20to$20render$20project$20list/xnat_discussion/rw2K7JTulvw/MXNK2x-vjC4J : problem solved in 1.4rc1
- https://groups.google.com/forum/#!searchin/xnat_discussion/Failed$20to$20render$20project$20list/xnat_discussion/1FmM7d8nGbA/pvhvXPs9aNYJ : I checked that this is not related to the cookies (as Thimothy answer)
As you said, this problem is probably not due to the LDAP authentication so maybe I should create a new topic for this?
All the best,
Mikael
PS: I paste below some logs I was able to track during the process:
In the webapps/xnat/logs/, two files are updated when I access the upload web-page:
access.log:
2014-11-05 10:08:22,177 - naveau 134.94.171.93 SCREEN: LaunchUploadApplet
2014-11-05 10:08:22,681 - naveau 134.94.171.93 GET https://nmrxnat.ime.kfa-juelich.de:8443/xnat/data/projects?format=json&permissions=edit×tamp=1415178502614&owner=true&member=true&rnd=1415178502614
velocity.log:
2014-11-05 10:08:22,206 [http-bio-8443-exec-16] ERROR velocity - RHS of #set statement is null. Context will not be modified. screens/LaunchUploadApplet.vm [line 110, column 13]
2014-11-05 10:08:22,206 [http-bio-8443-exec-16] ERROR velocity - RHS of #set statement is null. Context will not be modified. screens/LaunchUploadApplet.vm [line 111, column 1]
In
LaunchUploadApplet.vm, these two lines are located in this <script>:
<script type="text/javascript">
#set($project = $om.getProject())
#set($part_id = $!subject)
window.projectSubjectVisitManager = new ProjectSubjectVisitSelector("$!project", "$!part_id");
window.projectSubjectVisitManager.init();
jq('body').on('change', '#project, #part_id, #session_date', function(){
window.projectSubjectVisitManager.manageLaunchUploaderButton();
});
</script>
On Tuesday, November 4, 2014 5:49:47 PM UTC+1, Mike McKay wrote:
Mikael,
I’m glad to hear the authentication is now working for you. These other errors may be the result of it not setting up your site URL properly. What is the value of xdat.url in your build.properties file? Does it include a /xnat and is there a / at the end? For reference, on my local xnat instance the value of xdat.url is http://localhost:8080/xnat . You may find this discussion helpful to your situation: https://groups.google.com/forum/#!msg/xnat_discussion/kGrXf3_4FMA/R_sR3Pl3ofEJ .
...
at org.<span class="styled-by-pre
Herrick, Rick
Rick Herrick
Sr. Programmer/Analyst
Neuroinformatics Research Group
Washington University School of Medicine
Reply-To: "xnat_di...@googlegroups.com" <xnat_di...@googlegroups.com>
Date: Wednesday, November 5, 2014 4:33 AM
To: "xnat_di...@googlegroups.com" <xnat_di...@googlegroups.com>
Subject: Re: [XNAT Discussion] LDAP: username with special characters
As mentioned in the discussion you linked, the creation of a new user in the database (not using LDAP this time) solve the problem at the tomcat startup. I also double check that xnat is not configured as the root application in tomcat.
However, I still have an error when I try to upload images using the web interface.
Access: https://nmrxnat.ime.kfa-juelich.de:8443/xnat/app/template/LaunchUploadApplet.vm
First popup:
ERROR
:Failed to render
project list:TypeError:this.projectResultSet
isundefined
ERROR
200:Failed
to parse project list.
- the error appear both for the LDAP users and the database users
- I checked that the xdat.url is right in the build.properties (xdat.url=https://nmrxnat.ime.kfa-juelich.de:8443/xnat)
- two discussions already mentioned this problem (in 2009):
- https://groups.google.com/forum/#!searchin/xnat_discussion/Failed$20to$20render$20project$20list/xnat_discussion/rw2K7JTulvw/MXNK2x-vjC4J : problem solved in 1.4rc1
- https://groups.google.com/forum/#!searchin/xnat_discussion/Failed$20to$20render$20project$20list/xnat_discussion/1FmM7d8nGbA/pvhvXPs9aNYJ : I checked that this is not related to the cookies (as Thimothy answer)
As you said, this problem is probably not due to the LDAP authentication so maybe I should create a new topic for this?
All the best,
Mikael
PS: I paste below some logs I was able to track during the process:
In the webapps/xnat/logs/, two files are updated when I access the upload web-page:
access.log:
2014-11-0510:08:22,177-
naveau 134.94.171.93
SCREEN:LaunchUploadApplet
2014-11-0510:08:22,681-
naveau 134.94.171.93
GET https://nmrxnat.ime.kfa-juelich.de:8443/xnat/data/projects?format=json&permissions=edit×tamp=1415178502614&owner=true&member=true&rnd=1415178502614
velocity.log:
2014-11-0510:08:22,206[http-bio-8443-exec-16]
ERROR velocity - RHS of
#set statement is null. Context will not be modified. screens/LaunchUploadApplet.vm [line 110, column 13]
2014-11-0510:08:22,206[http-bio-8443-exec-16]
ERROR velocity - RHS of
#set statement is null. Context will not be modified. screens/LaunchUploadApplet.vm [line 111, column 1]
In
LaunchUploadApplet.vm,
these two lines are located in this <script>:
<scripttype="text/javascript">
#set($project
= $om.getProject())
#set($part_id
= $!subject)
window.projectSubjectVisitManager
=newProjectSubjectVisitSelector("$!project","$!part_id");
window.projectSubjectVisitManager.init();
jq('body').on('change','#project,
#part_id, #session_date',function(){
window.projectSubjectVisitManager.manageLaunchUploaderButton();
});
</script>
On Tuesday, November 4, 2014 5:49:47 PM UTC+1, Mike McKay wrote:
Mikael,
I’m glad to hear the authentication is now working for you. These other errors may be the result of it not setting up your site URL properly. What is the value of xdat.url in your build.properties file? Does it include a /xnat and is there a / at the end? For reference, on my local xnat instance the value of xdat.url is http://localhost:8080/xnat . You may find this discussion helpful to your situation: https://groups.google.com/forum/#!msg/xnat_discussion/kGrXf3_4FMA/R_sR3Pl3ofEJ .
And to answer your side question, we are getting very close to release to certifying it as production ready, and just need final sign-off from our test team. I expect that if there are any last-minute fixes that get in to 1.6.4, they will be small enough that you can easily update your instance of XNAT to include them. I think the chances are low that there would be major problems with using the current development tip on production, but it all depends on how risk-averse you are.
Let me know if there’s anything else I can help with!
-Mike
From: xnat_di...@googlegroups.com [mailto:xnat_di...@googlegroups.com] On Behalf Of Mikaël Naveau
Sent: Tuesday, November 04, 2014 7:58 AM
To: xnat_di...@googlegroups.com
Subject: Re: [XNAT Discussion] LDAP: username with special characters
Mike,
Here is some results about the tests I ran today:
First the good news!
- Authentication using LDAP works fine and replace the special characters by an underscore
- User can create their own project and the sql statement doesn't failed anymore
- I didn't notice any trouble related to the DicomReceiver, data are correctly assign to the corresponding user project and archive accordingly
Now some issues I got, but maybe not related to your fix:
- At the start of the tomcat server, this exceptions are thrown:
[localhost-startStop-1] ERROR xft.ItemWrapper -
org.nrg.xft.exception.ElementNotFoundException:Elementnot found:'xdat:user'
at org.nrg.xft.meta.XFTMetaManager.FindElement(XFTMetaManager.java:219)
at org.nrg.xft.meta.XFTMetaManager.GetWrappedElementByName(XFTMetaManager.java:363)
at org.nrg.xft.schema.Wrappers.GenericWrapper.GenericWrapperElement.GetElement(GenericWrapperElement.java:163)
at org.nrg.xft.XFTItem.NewItem(XFTItem.java:203)
at org.nrg.xft.ItemWrapper.getItem(ItemWrapper.java:223)
at org.nrg.xdat.base.BaseElement.readExternal(BaseElement.java:449)
at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1837)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1796)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1990)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1915)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
at org.<span class="styled-by-pre
...
To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To post to this group, send email to xnat_di...@googlegroups.com.
Visit this group at http://groups.google.com/group/xnat_discussion.
For more options, visit https://groups.google.com/d/optout.
Mikaël Naveau
Here is what I have in the developer console when reloading the page:
GET https://nmrxnat.ime.kfa-juelich.de:8443/xnat/app/template/LaunchUploadApplet.vm [HTTP/1.1 200 OK 124ms]
NS_ERROR_XPC_SECURITY_MANAGER_VETO: unity-global-property-initializer.js:238
GET https://nmrxnat.ime.kfa-juelich.de:8443/xnat/data/projects [HTTP/1.1 200 OK 8ms]
GET https://nmrxnat.ime.kfa-juelich.de:8443/xnat/data/version [HTTP/1.1 200 OK 5ms]
content is null tab-events.js:40
Use of getPreventDefault() is deprecated. Use defaultPrevented instead. jquery-1.8.3.min.js:2
content is null tab-events.js:40
Here are the URL called:
https://nmrxnat.ime.kfa-juelich.de:8443/xnat/data/projects?format=json&permissions=edit×tamp=1415266693696&owner=true&member=true&rnd=1415266693697
return:
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><body><table class="x_rs_t" cellpadding="0" cellspacing="0">
<thead class="x_rs_thead">
<tr class="x_rs_tr_head"><th>id</th><th>secondary_id</th></tr>
</thead>
<tbody id="dataRows">
<tr class="x_rs_tr_data odd">
<td>mnaveau_001</td><td>mnaveau test project</td></tr></tbody>
</table></body></html>
If use wget I obtain the correct json format:
wget --http-user=m.naveau --http-password='*****' --no-check-certificate --auth-no-challenge "https://nmrxnat.ime.kfa-juelich.de:8443/xnat/data/projects?format=json&permissions=edit×tamp=1415266693696&owner=true&member=true&rnd=1415266693697"
{"ResultSet":{"Result":[{"id":"mnaveau_001","secondary_id":"mnaveau test project"}]}}
https://nmrxnat.ime.kfa-juelich.de:8443/xnat/data/version?_=1415266693759
return:
Thank you for your help!
Mikael
...
at org.nrg.xft.ItemWrapper.getItem(ItemWrapper.<span style="font-size
Mikaël Naveau
I forgot the <TOMCAT>/webapps/xnat/logs.
When I hit: https://nmrxnat.ime.kfa-juelich.de:8443/xnat/data/projects?format=json&permissions=edit×tamp=1415268398345&owner=true&member=true&rnd=1415268398345
The access.log is updated with this line (no update in the other logs):
2014-11-06 11:07:06,130 - m_naveau 134.94.170.3 GET https://nmrxnat.ime.kfa-juelich.de:8443/xnat/data/projects?format=json&permissions=edit×tamp=1415268398345&owner=true&member=true&rnd=1415268398345
All the best,
Mikael
...<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rg
Herrick, Rick
Hi Mikael,
I tracked this bug down. It’s weird that it appears to have been working properly in Chrome but not in Firefox. It was only when I went to test something else unrelated in Firefox that I hit this error.
Anyway, I missed one line of code in another fix and that led to the this.projectResultSet undefined error. I’ve checked a fix for this into the dev line. If you update to the latest code, you should have the fix for this issue.
Sr. Programmer/Analyst
Neuroinformatics Research Group
Washington University School of Medicine
--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
xnat_discussi...@googlegroups.com.
To post to this group, send email to
xnat_di...@googlegroups.com.
Visit this group at http://groups.google.com/group/xnat_discussion.
For more options, visit https://groups.google.com/d/optout.
Mikaël Naveau
Thank you very much, it works like a charm!
Thanks again to Mike and you for your help,
Mikael
...