[MGNLPUR-17] defaultBaseUrl used in the email.html template should get it's value from the request URI Created: 21/Jul/08  Updated: 04/Oct/13  Resolved: 04/Oct/13

Status: Closed
Project: Magnolia Public User Registration
Component/s: None
Affects Version/s: None
Fix Version/s: 1.1.4

Type: Improvement Priority: Minor
Reporter: Will Scheidegger Assignee: Magnolia International
Resolution: Outdated Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File MailInContext.java     Text File RegisterInContext.java     Text File RegisterInContext.java     File config.modules.public-user-registration.config.contexts.xml     HTML File emailWithContext.html     HTML File user-registration-in-context.html    
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

The registration confirmation mails sent out use "defaultBaseUrl" to setup the link which lets the user confirm his/her registration. This value is taken form config:/server/defaultBaseUrl which makes it impossible to use PUR on more than one domain in an instance. It would be preferable if the base url + context path would be derived from the request URI.



 Comments   
Comment by Magnolia International [ 22/Jul/08 ]

You don't always have a request when generating an email, which is the point of the defaultBaseUrl setting (think about sending an email from a workflow). If you need a different behaviour than a single possible baseurl, you can always swap the behaviour that sends an email with a custom one, which is the whole point of these "behaviours", too.

Also, deriving the baseurl from the request does not always work either - think reverse proxies. defaultBaseUrl actually give you the benefit of choosing how links for external systems (emails, ...) look like.

Comment by Will Scheidegger [ 24/Jul/08 ]

I extended PUR to allow user registration in a certain context (e.g. a domain). Inside the PUR config folder a "contexts" folder must be created, which will contain configurations for each context to be used. If some config value in a context is not provided, the default value will be used. A sample contexts configuration is also attached.

I'm sure that the code is pretty crappy because I don't have all the insight yet in the magnolia "secrets" Still: It works well and you may add it to PUR if you think this might be a valuable extension.

-> I guess I will do the same thing for the other actions too.

Comment by Magnolia International [ 24/Jul/08 ]

thanks.
A few remarks:

  1. the whole reading of the configuration nodes seems unnecessary, you should be able to get that out of the config bean, as a Map<String contextName, Config> for example.
  2. testcases to ensure the ctx configuration properly overrides the defaults would be welcome (and much easier to write if you didnt use nodes directly - as suggested in #1)
  3. sample bootstrap files would be nice too - note that if using Content2Bean (indirectly, as suggested in #1), javadoc would be sufficient - at some point, we're hoping to be able to generate configuration documentation out of java code/doc.
Comment by Magnolia International [ 23/Jul/09 ]

Attaching this to version 1.2 for now for review; my current position on this is that this would probably be more beneficial if configured "globally" rather than in this module. The Link API could use make use of it. It is also somehow redundant with the site configuration introduced in stk/etk.

Generated at Mon Feb 12 06:42:16 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.