Is it possible to run one AzerothCore worldserver and one TrinityCore worldserver and have them to share the same authserver?
If yes, which authserver should I select?
Also, what about permissions? Since for commands permissions, AzerothCore is using the MaNGOS-like account_access while TrinityCore is using RBAC ?
Yes,
You can use the authserver of Trinitycore (Need to use auth database of Trinitycore too).
Add missing tables & fields of tables from azerothcore auth database to your trinitycore auth database. (For find missing run worldserver of azerothcore to see what fields of tables are required to import on error messages. like ip2location tables.)
For permissions, TC uses RBAC, So you must manage RBAC with your TC worldserver.
For AC, you must manage the commands table.
If you want to make a gm account on TrinityCore realm. use worldserver command account set gmlevel.
for AC realm you must use this command on AC worldserver.
Related
I have multiple services (Administration.Api, Project.Api)
Administration service is managing permissions (create,update).
But i have a problem about caching, when i update permissions through Administration.Api, Project api's cache Permission grant don't change immediately(it's grant change after 20minutes, when cach removed automatically)
I want to change all permission cache under different cache prefixes immediately. How can i fix this?
You really need a true distributed cache service (like Redis) to do this properly. That way a cache-dump for one affects all services.
There are other solutions you could try, but really they are just bandaids, and more work with potential other sideeffects.
use a message bus to notify all services of the permission change and to dump their in-memory cache
use a new shared db table to add a new row with "LastUpdated". The permission service would need to write the updated time when permissions changed. Each service would need to query this table to check for a newer updated time (on each request), and dump in-memory cache if exists.
You can use AbpDistributedCacheOptions to change default cache settings and add prefix to your application for caching.
Configure<AbpDistributedCacheOptions>(options =>
{
options.GlobalCacheEntryOptions = new DistributedCacheEntryOptions()
{
AbsoluteExpiration = //20 mins default
};
options.KeyPrefix = "MyApp1";
});
You can also extend override permission management providers, such as RolePermissionManagementProvider and handle cache invalidation.
Docs about permission management providers: https://docs.abp.io/en/abp/latest/Modules/Permission-Management#permission-management-providers
One application has ONE ABP default cache (we are not talking about global caches like Redis now). So to have a single control of different applications caches, you can use RabbitMQ: you have a RabbitMQ queue in each application, named something like "abp-cache[appName]". In RabbitMQ receiver, you send messages to EACH of these queues. In the RabbitMQ receiver of the specific app, you handle the received message. I've already implemented this mechanism to update ABP permission cache for all my apps. Everything is easily wrapped inside Extensions Nuget package.
I want to use dynamic databases on runtime without effecting config/database.php because of concurrent users.
I have a main db with a table that contains reference to several other dbs. Now at runtime I need to not only connect to those dbs but also may want to run migrations on them.
I am aware that this is possible by having a second connection entry in config.database.connections but I have a feeling that if two users hit the server at the same time, the physical config file changes may create a conflict.
I also read (and also experimented) that you can edit the second connection using below code at runtime:
\Config::set('database.connections.mysql2.database', 'somedynamicdb');
DB::purge('mysql2');
But I fear that if it persists changes for different users, then it may conflict for concurrent users. And if it does not persist changes, then it wont work for migrations.
I want to understand/know two things specifically:
What is the scope of this above code (i.e. Config::set() call)? Does it persist over different user calls to the server?
If I call migrations using Artisan::call('migrate') with a --database=connectionname clause, right after I change the db name in connectionname, will that use the dynamically set database or the physical config value?
UPDATE
Also worth noting that a call to Artisan::call('migrate') with a --database=connectionname, will make the new connection persist for the rest of your app call.
See here for details:
https://github.com/laravel/framework/issues/28253
Config::set will only apply for the request for which it was set, won't apply to any other requests, and will not persist beyond the request. If you're not processing a request (e.g. a CLI command) then it won't affect anything beyond the current PHP process.
As for Item #2, if you're invoking from the command line, you can just do DB_CONNECTION=connectionname php artisan migrate. If you need to invoke the artisan command from code, using Config::set is still the right way to go.
We use connection created on the fly here all time and works very well. We setup this on Middleware that we included after authentication and is only valid on the user current user request based on login information.
I'm working on a tool that generates .rdp files and then invokes them using Microsoft RDP Client. This tool is running on Mac OS.
Everything works well, the only problem is that I can't figure out of how I can generate 'password 51:b' field properly. On Windows this can be done easily by using CryptProtectData method from Crypt32.dll library. How can I do the same on Mac.
Another option could be to use "rdp://" URL scheme, but it doesn't seem allow to pass password this way.
So the question is how can I implement auto-login on Mac if I use third-party RDP client.
As far as i know you can't. You can however create a "User Account" and a Server configuration and add both to the client. The connection will then be visible on the main window and you just need to double click it.
To do so, you need to add the password to the Keychain, use /usr/bin/security to do so from a script. It needs to be a generic-password and saved in com.microsoft.rdc.macos. Also be sure to generate an ID according to the RDP Clients scheme, like BFF77777-7777-7777-7777-777777777777.
You may also set the permissions to read that key using /usr/bin/security and set-generic-password-partition-list specifying the right teamid (UBF8T346G9) and again com.microsoft.rdc.macos. You need the admin password to do this step.
Then you can alter the RDP Clients config file, which is a .sqlite file located at /Users/$(whoami)/Library/Containers/com.microsoft.rdc.macos/Data/Library/Application Support/com.microsoft.rdc.macos/com.microsoft.rdc.application-data.sqlite. Add the user configuration in the ZCREDENTIALENTITY table and make sure the ZID matches the one added to the keychain.
To add a server configuration you need to alter the ZBOOKMARKENTITY table. Just add a configuration by hand using the UI and look at the table to get a feeling of how it needs to be setup. Basically you link your user configuration with the server configuratio by making sure that ZCREDENTIAL in ZBOOKMARKENTITY matches Z_PK in ZCREDENTIALENTITY of your user configuration.
I know the answer is a bit late, but it may give you a starting point. This will however not fully automate the process, you will still need to go to the UI and double click the connection you want to use.
I am getting error "CWWIM4538E Multiple principals were found" at server startup. I know the cause as the local WAS admin account has its duplicate in LDAP repository. I simply wants to remove the local WAS user gracefully offline as server won't come up. I tried playing around with changing the user id info in fileregistry.xml and corresponding change in security.xml but to no avail.
Seems that you've added LDAP into "federated repositories" and forgot to remove "internalFileRepository" which contains wasadmin as well. You can do it in profiles/dmgr/config/cells/myCell/wim/config/wimconfig.xml, where you just remove it from the realm.
MSDN says: LookupAccountSid function returns the name of the first domain on which SID is found.
If a User is migrated to domain B from domain A and we query the old SID of user by using LookupAccountSid function from any machine of domain A, we get domain name of domain A instead of domain B.
It seems that even after migrating the user, Active directory is keeping user info on domain A. This problem is not resolved even after restarting the machines of domain A including domain controller.
I need name of new domain of User. Can you suggest how to resolve this issue?
The most Win32 API are designed to work in the environment where one account has one sid. Active Directory supports sidHistory attribute which can save additional SIDs. If you would use Active Directory API (for example ADSI) or LDAP API you can find the main users name, primary SID and all ather attributes which you need.
The most problem in answering on your question is that you don't describe the domain migration scenario which are planned and used in your organisation. When you plan to switch off the old domains controllers? Do you plan to clear the old SIDs saved in the file system, shares or in the registry?
It is important to know the full domain migration scenario, so that the program which you now write will continue to work on the next steps of domain migration. I recommend you to speak with administrators or the project manager of the domain migration project of your organization to understand what is exactly planned to do.