Page "Proposals/BEP-0003" was changed by olemis Diff URL: <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diff&version=14> Revision 14 Comment: [BEP-003] Sample product URL mappings TODO: Detailed request dispatching Changes: -------8<------8<------8<------8<------8<------8<------8<------8<-------- Index: Proposals/BEP-0003 ========================================================================= --- Proposals/BEP-0003 (version: 13) +++ Proposals/BEP-0003 (version: 14) @@ -211,15 +211,116 @@ === Product resources namespaces #url-mapping -Product and resource ID should form a two dimensional namespace. The mapping should be flexible enough to support the following scenarios . - - - '''Product path namespace''' : '''TODO''' - - '''Product sub domain''' : '''TODO''' - - '''Product sub domain + path namespace''' : '''TODO''' +Product and resource ID should form a two dimensional namespace. The mapping should be flexible enough to support the scenarios mentioned below. Other deployments may still be possible but are beyond the scope of this specification. However , in all cases every requests sent to any path under product base URL will be handled by the request handlers and filters activated in the target product environment. + + - [=#deploy-domain] '''Product sub domain''' : The base URL of products + will be at sibling sub-domains. A well-known + example is edgewall.org (i.e. bitten.edgewall.org , + genshi.edgewall.org , trac.edgewall.org ). + The global environment may be accessible at one + such sub-domain, at top level domain, or + somewhere else. + +{{{ +#!div class="well" + +{{{ +#!span class="label label-info" + + Implementation notes +}}} + +'''TODO''' + +}}} + + - [=#deploy-sibling-paths] '''Product path namespace''' : Each product is + accessible at sibling paths on the same domain. + The global environment will be available either at + one such path or somewhere else. + +{{{ +#!div class="well" + +{{{ +#!span class="label label-info" + + Implementation notes +}}} + +This case is very similar to the [./MultienvParentDir reference multi-environment setup] . + +'''TODO''' + +}}} + + - [=#deploy-global-env-embed] '''Embedded product path namespace''' : Each + product is accessible at sibling paths inside + the URL space of the global environment. + +{{{ +#!div class="well" + +{{{ +#!span class="label label-info" + + Implementation notes +}}} +Even if this case is very similar to the [./MultienvParentDir reference multi-environment setup] a better match will be another setup based on [trac:wiki:TracWsgiPlugin]. The main difference with respect to [#deploy-sibling-paths sibling paths] deployment is that the global environment plays an active role dispatching the requests addressed to an specific product by forwarding them to the corresponding product environment. + +'''TODO''' + +}}} + + - [=#deploy-domain-path] '''Product sub domain + path namespace''' : + In this case product prefix will be + matched against URL sub domain whereas + ''Bloodhound'' will be accessed at a given path + inside of it. This case is frequently offered by + hosting providers like forges deploying multiple + web applications for projects . In general + product base URL will look like + `http://<product prefix>.domain.tld/path/to/bloodhound` . + +{{{ +#!div class="well" + +{{{ +#!span class="label label-info" + + Implementation notes +}}} + +'''TODO''' + +}}} + + - [=#deploy-domain-path] '''Arbitrary product path namespace''' : + Sometimes hosting providers like forges do not + support sub-domains for products. Hence + product prefix is included in URL. + In general, product base URLs will look like this + `http://domain.tld/path/to/<product prefix>/path/to/bloodhound` . + One such hypothetical example would be + `http://sourceforge.net/p/<product prefix>/bloodhound` . + + +{{{ +#!div class="well" + +{{{ +#!span class="label label-info" + + Implementation notes +}}} + +'''TODO''' + +}}} '''FIXME''' also be addressable through the product URL namespace, namely /ticket/<product prefix>/<local ticket id>. -In a multi-product configuration product resources should not be accessed using current global URL scheme (i.e. /path/to/bloodhound/<environment>/<realm>/<id>). '''TODO''' why ? +In a multi-product configuration product resources should not be accessed using current global URL scheme (i.e. /path/to/bloodhound/<environment>/<realm>/<id>). Since [#permissions products will have their own permissions schema] then requests handled by components in the context of the top-level environment will perform neither the right permissions checks nor even use appropriate settings , and so on ... The same will happen for resources moved between products . In general such requests should be redirected to a URL under the namespace of resource's product. ==== Tickets #tickets-namespace -------8<------8<------8<------8<------8<------8<------8<------8<--------
-- Page URL: <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003> Apache Bloodhound <https://issues.apache.org/bloodhound/> The Apache Bloodhound (incubating) issue tracker This is an automated message. Someone added your email address to be notified of changes on 'Proposals/BEP-0003' page. If it was not you, please report to .
