How do I get my dropwizard application to operate against a specified schema, a schema other than the default 'public'?
The postgres user has all privileges on schemas 'public' and 'schema1'. It should be doing a lookups on 'schema1' tables but it comes back as (tablename) doesnt exist, even though it clearly does. This is because its looking at the 'public' schema
Should this be handled on the application side i.e dropwizard hibernate config, or on the database side. How should i tackle this? Is there a standard way?
Thanks guys
The dropwizard use a yml configuration file, in this file you can configure your database connection, the correctly use is the configuration file.
Related
I am on Apex 5.1 in a hosted environment and have an application that uses a custom LDAP authentication function. It works fine when the application is running on the Production schema. I now wanted to make some changes to the schema and application, so our hosting vendor added a 'DEV' schema on same instance with exactly the same data and objects as PROD and I then exported the application and used the DEV schema as the parsing schema when I imported it back to same Workspace so I could make changes to the application without touching prod data. This set up works fine when I use the Application Express authentication and go ahead and make changes to the DEV schema and to the application, but when I try to test my changes using the custom LDAP authentication, I am getting Invalid Session thrown by DBMS_LDAP. Since both schemas are on the same oracle server, I assumed that the same LDAP function that works in PROD schema should work with the DEV schema. Looking at the custom LDAP function, there is no reference to schema owner so what am I missing? I would have assumed identical functions should function identically against the same Oracle server even though coming from 2 different schemas. Does my hosting vendor need to make sure ACLs for both schemas (PROD and DEV) are identical??
Thanks,
Pat
My guess was correct. ACLs were not set identical for both schemas. Once ACLs were adjusted, LDAP worked as expected.
Is it possible in any of the existing LDAP servers to edit a schema in one of the editors available? Like JXplorer, Apache Directory Studio, LDAP Admin?
I tried with OpenLDAP and all of the above tools (I run the server with -F option) but it looks like it's not possible to modify schema - add new attributes, add descriptions etc.
I would be grateful if any of you have some experience with this.
Cheers
Some LDAP servers allow (authorized users) to change the schema by sending LDAP modify operation affecting the so-called subschema subentry directly, but not OpenLDAP.
In OpenLDAP you have two possible configuration methods:
Static file configuration usually with schema files being simply included (aka slapd.conf) which requires slapd to be restarted to make configuration changes effective
Dynamic configuration backend back-config (aka cn=config) for which you can also define ACLs restricting access to your LDAP admins
The dynamic configuration method allows to tweak the schema via LDAP making it effective without server-restart. But you have to modify the multiple LDAP entries in sub-tree cn=schema,cn=config which you can do with any generic LDAP client.
Since schema descriptions usually reference other schema descriptions the order is important. Standard LDAP does not know about order of entries beneath an entry or order of attribute values. Therefore OpenLDAP implements an extension specified in draft-chu-ldap-xordered.
I have a file (or set of files under a directory) published on my web server. Each of this resource needs to be access-protected based on the user's credentials and authority.
The authorization details are stored in a DB, so I need to make a call to the Java code in application server to determine the access.
Everytime the user hits this particular path in the webserver, I need to ensure s/he has access to the requested resource by, ensuring he is logged in and has the necessary priveleges to access this resource.
The webserver is apache - Can you please point me to the settings in apache that allows me to secure resource access using the above logic?
Thanks for the suggestions to correct the Tag and the Question!:
My Web Server is Apache HTTPD
Agree that this is not a Java Question: The only reason why I am bringing the Java perspective, is that I am most likely going to use some Java POJOs to go and check for user authorization for a particular directory that is stored in the DB - That is unless there is a trick in the apache httpd configuration that goes and checks the DB automatically - something similar to the one that is pointed out here...At the end of the it, I need to check if a particular user (authenticated previously by the Single Sign On Server (Sun access manager)) has access to a particular directory (user mapping to directory stored in the DB) and protect the resources under the directory accordingly.
Please let me know if that clarifies.
i am not sure why this is tagged with java - unless your db structure is VERY sepcific, you might able to get it done with apache authz and authn:
http://httpd.apache.org/docs/2.2/mod/mod_authn_dbd.html
or, for an ovierview:
http://httpd.apache.org/docs/2.2/howto/auth.html
We have SSIS package config files that contain DB encryption passwords or PGP encryption passwords. I came to the conclusion that there is no "silver bullet" solution for encrypting SSIS package config files like with web.config files ect.
Should we consider not using config files at all for SSIS packages and if so what other options do we have available for storing settings?
Encryption of configuration files are not handled by SSIS itself. You can use NTFS encryption and/or ACLs to control access to config files and contents. It beats learning and administering a new access/encryption mechanism, and nicely ties in to your AD efforts.
Another option is to store the configurations in a SQL table and use SQL security to control access, but most administrators seem to prefer file-based management.
Could you use a table for config storage and lock down access to it? Throw that database/log/backup in an EFS protected folder and the only people that could access would be SQL sysadmins/or authorized accts and whoever has access to decrypt efs with a recovery account and restore the database (domain admins?).
You could also use SQL 2005's native encryption and write your own procedure to access the data and then set the connection properties in a script task. I haven't done this, but theoretically it might work.
While storing configuration information in a database is a viable alternative, if you are stuck with XML configuration files (for a variety of reasons), you may try BI xPress Secure Configuration Manager or SSISCipherBoy (freeware, I am affiliated to this project). These two utilities answer your question precisely.
We've got an apache module in place for authentication. If the user is able to authenticate, the REMOTE_USER environment variable is set to their username, where it's available to any CGI they access.
I'd like to add a feature/module so that we can get additional information about the user from an LDAP data source and make it available to CGI and FCGI applications.
Since I know we can put information into the environment, is it appropriate to store a more complex data structure (such as JSON) in an environment variable? That seems clunky to me. Is there a better way to do it?
If it's language-dependent, then I'm most interested in Perl, but it would be best if I could make this data available to any type of CGI or FCGI application. We're using Apache 2.2 on RHEL 5.0 (with SELinux enabled).
If you need to work with CGI, environment variables seem to be the only option (with mod_perl, you can access Apache's internal data structures).
If the data is too large for the environment, you could create a temporary file and pass just the file name. You could also store this information in the database. In both cases, you probably need to worry about cleaning up the temporary data, and about race conditions with concurrent access.
If you already have persistent server-side session data (a session file or directory or shared memory segment), you may want to place it in there.