Same Domain - different Context: How to add users to indipendent context

[thiel]

Hi!

How should this be done:

I have 2 user: "user1" and "user2"
Both have the same domain: "domain.com" and their email is "user1@domain.com" and "user2@domain.com"

Both should have their own area in their own context. Problem is the mapping. I can add a mapping "domain.com" to one context, but not simultaneously to the second context.

What is the best way? Is it possible to switch off the mapping? Why is it not possible to use the whole email as mapping?


---

Nochmal auf deutsch:

Wenn ich 2 User habe die die selbe Domain nutzen, wie kann man beiden trotzdem einen eigenen Context zuordnen? Es geht darum, dass jeder der User seinen eigenen Drive-Speicherplatz bekommt und sich das nicht teilen muss. Aber die Domain und Domain der E-Mail Adresse bleibt gleich.
Mit dem Mapping oder dem Context-Namen geht das ja nicht, da man nicht mehrmals die selbe Domain

mappen kann. Kann man das mapping abschalten? Könnte man die ganze E-Mail Adresse als Mapping nutzen?

dann könnte man ja mehrere Adressen als Mapping eintragen wenn man dann doch mal mehrere User pro Context nutzen möchte.

[pro-ite]

Why not separating the storage with group/user rights for personal or public drive directories?

To use more contexts with identical mail domains use this workaround with domain alias and mail aliases

The user login name can be different to the main mail address.
Context1: main domain "domain1", user name for login and as mailaddress: userA@domain1
Context2: main domain "domain2," user name for the ox login: userB@domain2, user mail adress alias: userB@domain1
UserB has a different login domain but his default mail address is domain1

HTH
pro-ite

[Wolfgang Rosenauer]

If the above suggestion is not sufficient you would have to use a modified auth bundle and another concept to identify and map users to contexts.
This would involve some Java coding knowledge though.

[pro-ite]

A high risk

If the above suggestion is not sufficient you would have to use a modified auth bundle and another concept to identify and map users to contexts.
This would involve some Java coding knowledge though.

What!? We seldom discuss such ideas public. But this is ....

I disagree: we tried several add-ons and a recurring lack is the corruption after updates. This happens also sometimes with OX supported opptions! The securing and trimming of the self made code to prevent bad effects after updates is a challange.

A broken log in after updates would break the connect for the users. It's a high risk. So it's tricky and not recommendable to add code in such sensible areas if you need separated data.

[Wolfgang Rosenauer]

Hmm, you are exaggerating I think but yes, there is some risk in case of such customizations. The auth API though is very small and pretty stable. What I just said was that if the proposed workaround is not sufficient then there is another way.
I wrote my auth plugin in 2010 and had to update it only once since because of an api change. In any case any acceptable option w/o adding custom code is preferred obviously.

[pro-ite]

I wrote my auth plugin

What is it: a auth plugin? And also optional for content separation? Sounds great if your plugin works/can be configured also as content separation. Since 2010? That sounds like real good stuff
I'm nosey. Would you please post your plugin for the community? Or if available a common usable snippet?

[Wolfgang Rosenauer]

Not sure what you mean by "content separation". The original question was how to implement to have separate contexts for the same maildomain.
Since the loginname <-> uid, cid mapping can be implemented in the auth plugin this would be possible there. Also I don't need to post it here since all the examples are open source. Get the bundles for the imap, database and ldap authentication plugins and you have plenty examples. My plugin is tailored to my environment and is based on the open-xchange-authentication-imap plugin but has like 10 more lines.

[pro-ite]

Ooops, wrong word in our last post: content!
No, not content: we ment CONTEXT separation. Dear Wolfgang Rosenauer. Thank you for specifying what can be done with loginname/uid. Auth check for each user with his id/ loginname is an option, I agree.