So I'm attempting to use subdomains using the tenant's name to resolve such. In my case, working in local host, I edited my host file to point to a new tenant named subdomains to the localhost application.
I'm able to go-to the page and it loads properly using test.mydomain.com:[port] but it does not seem to honour the domaintenantresolver I set up in ConfigureServices. Is this a completely wrong approach to test subdomain multitenancy?
The code below is the function I added in which I call in ConfigureServices. I also added the following lines to my host file:
127.0.0.1 www.mydomain.com
127.0.0.1 www.meme.mydomain.com
private void ConfigureTenantResolver(ServiceConfigurationContext context, IConfiguration configuration)
{
Configure<AbpTenantResolveOptions>(options =>
{
options.TenantResolvers.Insert(1, new DomainTenantResolveContributor($"{0}.mydomain.com:44327"));
// OR
// options.AddDomainTenantResolver($"{0}.mydomain.com:44327");
options.TenantResolvers.Add(new QueryStringTenantResolveContributor());
options.TenantResolvers.Add(new RouteTenantResolveContributor());
options.TenantResolvers.Add(new HeaderTenantResolveContributor());
options.TenantResolvers.Add(new CookieTenantResolveContributor());
});
}
Related
Myapp is java springboot microservice deployed in kubernetes. In local it works fine since I do not need proxy and kubernetes.yml, however when I deploy to int environment, I run into "404 page not found" error.
Please advice if there is any other way to call the service endpoint with this path /api/v1/primary-domain/domain-objects?parameter1=645¶meter2=363¶meter3=2023-02-01
Why is it not able to find the resource? Are there any options to make this work still with same naming pattern for path?
application.properties
server.servlet.context-path=/api/v1/primary-domain/domain-objects management.endpoints.web.base-path=/ management.endpoint.health.show-details=always management.endpoints.web.path-mapping.health=health
#API Registry
springdoc.api-docs.path=/doc
controller:
`#GetMapping(value="", produces = MediaType.APPLICATION_JSON_VALUE)
public ResponseEntity<List<DomainObjectsMsResponseDTO>> getDomainObjects(
#RequestParam(name = "parameter1", required = false) String parameter1,
#RequestParam(name = "parameter2", required = false) String parameter2,
#RequestParam(name = "parameter3", required = false) String parameter3,
) throws Exception{..}`
The path variable in proxy is /v1/primary-domain/domain-objects
proxy.yml
.
.
spec: path: /v1/primary-domain/domain-objects target: /api/v1/primary-domain/domain-objects
.
.
Due to the architecture direction the path for health, doc and actual service endpoint should follow certain naming convention, hence running this issue.
If I use proxy.yml path variable v1/primary-domain and getMapping( value="/domain-objects"..) then it works fine but the domain-objects/doc endpoint returns sever array with url: api/v1/primary-domain, which is not what I want. Since under primary-domain multiple microservices will be created which will be in their own gitRepos and they will path like /primary-domain/points and /primary-domain/positions
I tried getMapping( value="/"..) and removing value variable entirely from getMapping, but still getting same error
I tried changing the Label variables, path target and paths in kube and proxy and matched the app.proeprties and controller to go with it. However with every approach one thing gets broken. None of the approach satisfies endpoint, health endpoint, doc endpoint( open api)
I moved my login controls from account/login to the home page and removed the account controller and it's views. It all works fine on my machine (of course) but when I deploy to my test environment I get an error:
No webpage was found for the web address: https://identity.blah.blah/account/login?returnUrl=%2Fconnect%2Fauthorize%2Fcallback%3Fclient_id%3Dclient.js%26redirect_uri%3Dhttp%253A%252F%252Fblah.blah%26respons etc
My front end is Angular 6 and Im using angular-auth-oidc-client.
There's nothing in my code that creates this url. The sts server url is just the root uri, no account/login.
{
"stsServer":"https://identity.blah.blah",
"redirect_url":"http://app.blah.blah",
"client_id":"app.client.js",
"response_type":"id_token token",
"scope":"openid profile api.v1",
"post_logout_redirect_uri":"http://app.blah.blah",
"start_checksession":true,
"silent_renew":true,
"startup_route":"/",
"forbidden_route":"/forbidden",
"unauthorized_route":"/unauthorized",
"log_console_warning_active":true,
"log_console_debug_active":false,
"max_id_token_iat_offset_allowed_in_seconds":"10"
}
Anyone got any ideas? Maybe this is something hard coded somewhere I need to override?
Found it finally. Not the best documentation... :/
var builder = services.AddIdentityServer(SetupIdentityServer)
private static void SetupIdentityServer(IdentityServerOptions
identityServerOptions)
{
identityServerOptions.UserInteraction.LoginUrl = "/";
identityServerOptions.UserInteraction.LogoutUrl = "/Home/Logout";
}
I'd like to access the security config as it's configured (by default) in security.yml, and in particular actually I need the route name or (even better) generated URL to login. When using FOS User (which I'm using right now) its called "fos_user_security_login" with "/login" URL. I need it to compare with an event's request's (requsted) URL on Kernel's listened events.
I could hardcode this setting check in my Kernel Listener class, like this:
public function onKernelResponse(\Symfony\Component\HttpKernel\Event\FilterResponseEvent $event)
{
if ($originalResponse->headers->has('location')
&& $originalResponse->headers->get('location') === $router->generate('fos_user_security_login', array(), true))
{
//...
}
}
But what if I changed this setting in future to some another one, e.g. to some "/user/login" path with my custom login handler? This is why I'd like to read the security setting for login.
How can I do this in Symfony?
If I were you I would refrain from reading the security settings for this as you can have multiple firewalls with multiple logins and your listener would thus have to listen to all of these (which might not be what you want) or artificially restrict to hardcoded firewalls. Also this will tie your implementation to Symfony's security-component, which you should avoid.
An easily reusable approach would be, to add the URL or route name you want to check for as argument to your listener and pass it via Symfony's Service Container and then just compare request with that value:
class LoginListener
{
/**
* #var string
*/
protected $loginUrl;
/**
* #param string $loginUrl
*/
public function __construct($loginUrl)
{
// You can even fallback to default if you like:
if (empty($loginUrl)) {
$loginUrl = '/login';
}
$this->loginUrl = $loginUrl;
}
// [...] your comparison just against $this->loginUrl
}
You can then use your bundle's configuration to pass the right argument to that listener.
This way you can easily reuse it outside of Symfony e.g. in Silex without being tied to Symfony's Security-component. Also if you want to check against multiple urls, you can just make it an array and specify the different login urls, e.g. when you have multiple login-mechanisms.
edit: In your bundle's Configuration you can check for parameters and define your fallbacks or an error message or whatever (see Getting and Setting Container Parameters).
edit:
in parameters.yml:
custom_login_path: /my_login
in security.yml:
main:
pattern: ^/
form_login:
provider: fos_userbundle
csrf_provider: security.csrf.token_manager # Use form.csrf_provider instead for Symfony <2.4
login_path: %custom_login_path%
in routing.yml:
fos_user:
resource: "#FOSUserBundle/Resources/config/routing/all.xml"
# Make sure this follows "fos_user" so it takes precendece over the default
fos_user_security_login:
path: %custom_login_path%
defaults: { _controller: FOSUserBundle:Security:login }
in config.yml:
# config for listener in your bundle
my_bundle:
login_path: %custom_login_path%
How to get app domain name? (I mean base url without protocol http:// or https://)
So if app is installed on 'http://sub.example.com/app', I want to get 'sub.example.com'.
There is the PHP global $_SERVER['HTTP_HOST'] - this will return the domain without protocol, but won't give you a sub-directory, e.g. if your app is at www.domain.com/myapp/app.
Assuming you are referring to a CakePHP app (given the tag on the question), you can use the following constant upto version 2.4:
FULL_BASE_URL
In version 2.4 you can use:
Router::fullbaseUrl()
This returns the base URL with http:// or https://. You can then do a regex replace to get rid of that part.
Try:
function replace_http($url) {
$pattern = "https{0,1}:\/{2}";
return preg_replace($pattern, "", $url);
}
$baseUrl = replace_http(Router::fullBaseUrl());
I use this in my config.php/bootstrap.php which is located in config folder to get url app domain with folder
$_SERVER['HTTP_HOST'].dirname(dirname(dirname($_SERVER['PHP_SELF'])));
I'm on a shared host and ini_set function is disabled for security reasons. I'm trying to deploy CakePHP 2.4.1 on this host. Fresh cake installation results in a blank page, with no errors shown, instead if I comment these lines:
\lib\Cake\Model\Datasource\CakeSession.php
if (empty($_SESSION)) {
if (!empty($sessionConfig['ini']) && is_array($sessionConfig['ini'])) {
foreach ($sessionConfig['ini'] as $setting => $value) {
if (ini_set($setting, $value) === false) {
throw new CakeSessionException(__d('cake_dev', 'Unable to configure the session, setting %s failed.', $setting));
}
}
}
}
Everything seems to works fine. Now, I'm asking what is the downside of keeping that snippets commented (in other word, what is that code responsible for)?
As the exception message, the method name and the rest of the code indicates, it configures the session settings, session name, cookie lifetime, save handler, etc...
Your code may run fine, and you should be able to use the PHP session_*() functions instead to configure the settings (the best place for that would probably your bootstrap.php). Also writing a dummy value into $_SESSION seems to prevent the CakeSession::_configureSession() to use ini_set(), so you don't have to modify it.
So this might work, but it shouldn't be necessary to jump through such hoops. There's no need to disable ini_set() in a properly set up shared hosting environment, and personally I'd change the hoster in case they are unable to change this behaviour.