Existence of user home is assumed

[montesmariana]

First of all: good news! We can use rirods in the production environment at KU Leuven!
However, we have noticed that rirods assumes the existence of a user home (/zoneName/home/username/), which we don't normally support. Users have access to group-level collections instead. This assumption seems unncessary and it's preventing from running ils(), icd() even outside of that non-existent collection.
Could we change that, and leave the definition of the landing collection to the configuration file?

[trel]

Most definitely.

[trel]

I think we have to leave a default in place if there is no configuration defined... and /zoneName/home/username still feels correct for most cases.

We can work on a named configuration option that would override the default.
The equivalent in the ~/.irods/irods_environment_file.json is irods_home.

Should that also be an additional optional parameter to iauth() which makes its way into the local configuration file?

[korydraughn]

Should that also be an additional optional parameter to iauth() which makes its way into the local configuration file?

I don't think so. Let iauth() give the user a way to temporarily override the information loaded from the file. If the user finds themselves doing that frequently, they can manually edit the file and set the appropriate collection as their home collection.

[montesmariana]

I would add it as a parameter to create_irods(). Originally it had a parameter to select the zone, which is now redundant with the hostname of the HTTP API, so we could add an irods_home argument instead.

[montesmariana]

But maybe iauth() could trigger a check that the home actually exists. If the home exists, users can actually move around to other collections that they have access to outside of their home; what happens with the current code is that it takes the home as starting point, and when it doesn't exist it crashes.

[MartinSchobben]

I haven't touched the code for a while but I think that the suggested changes to both create_irods() and iauth() can be done fairly easily. For the latter check, the internal lpath_exists() function might do the trick.

[korydraughn]

@montesmariana Sounds reasonable to me.

[montesmariana]

Checking the code again, this make_irods_base_path() function seems to be used by lpath_exists() itself and to set the current directory. I would split those things:

• Setting the "home" directory could be done via the configuration and maybe overriden. In ManGO portal we call this a realm, and it's very handy to set which it is from the beginning.
• Checking that a path exists should not be done only within that home directory, but from the /zone/... itself (and I would venture: from /zone/home/; would we need to go higher?). In that case, just building zone_name + home is enough.

The code right now builds that home based on the role of the user, but in any case, if a user asks to see the contents of /zone/home/ they will only see what they have permissions to see anyways, correct?

[korydraughn]

The iRODS server will only allow users to view what they have permission to view. If the user attempts to access a collection they don't have permissions to, an error will be generated by the iRODS server.

Given that the server detects invalid collection access, I think allowing any logical path to be set is the best way to future proof the code (just like icommands). Users attempting to access / or /<zone> probably isn't something you have to guard against or worry about. Providing recommendations/guidelines in the form of documentation should be good enough for users IMO. Well, providing good defaults is a good idea too.

Thoughts?

[montesmariana]

Made a PR but cannot assign reviewers

[korydraughn]

Reviewer assigned.