I have some custom attributes in Active Directory. The attributes are populated via code.
Does AD support automatic encryption/decryption of the values stored in these attributes or should my code do the encryption/decryption prior to writing/reading the attribute?
Thanks!
What syntax (Case Insensitive String, Unicode String, etc) did you make the attributes when you added them?
Really, that doesn't matter as you'll just be setting the values when writing to AD so you'll have to do the Encryption/Decryption yourself.
Related
(I've already asked this on the W3/JSON mailing list, I'll try here too.)
I'm fairly new to JSON-LD, although I have significant experience with Semantic Web technologies.
I've read the guideline document (https://www.w3.org/TR/json-ld/) and I haven't get if the feature at issue is supported:
Suppose you have JSON objects of #type Person and #type Address, both having the #id property. Typical API-coming data will have values like integers or some internal, context-dependant IDs. It's pretty common to RDF-translate those values to prefix-based URIs like http://www.example.com/Person/123 or http://www.example.com/Address/xh324m44.
What I would like to do is to specify those prefixes and keep data telling #id = '123', with the value joins happening at RDF serialisation stage (the same specification would make it possible to do the opposite conversion too). Clearly, in such a use case, the prefixes depend on the #type of objects, and the #base mechanism is not enough. Moreover, it would be useful to have this mechanism available for properties too, e.g., to associate the address URI prefix to the values of the "address" JSON property.
It doesn't seem that this is currently available in JSON-LD, or am I missing something? Any plan for future extensions?
You can use #base in the context to create a URI base for values of #id, but this will not include something from #type. This sounds like something you might get by defining a URI template and using variables to expand type and id to create a URI. You can do this in a templating language and create the JSON-LD, but not directly in JSON-LD itself. Not likely to be a feature included by the language in the future, either, as it's application is pretty narrow.
I am using this great encrypt/decrypt package.
It encrypts data before prePersist and decrypts is automatically postPersist.
At one part of my project I need the plain (encrypted) value from the database, is that in any way possible?
I identified this (processFields) as the right function to change I believe, but what do I have to do?
I changed Line 277 to $entity->$setter($getInformation); but 1. that means NONE of the values are decrypted, and 2. it does not seem to have any effect though.
How do you retrieve the data to be decrypted? IF you use standard DQL, when hidratate the object you have the plain data. Otherwise you need to do by yourself thru the exposed service, something like, example in a controller:
$pain = $this->get('ambta_doctrine_encrypt.encryptor')-> decrypt($encrypted);
Hope this help
I wanted to create a blank Component in SDL Tridion 2011 using the Core Service. The only information I have at the start of the process is the Schema URI. The Schema may contain any kind of field (text, rtf, number date, embedded etc), some of which may be mandatory.
I understand that for the mandatory fields, I will need to save some dummy value in them, and this is acceptable as they will be changed manually later.
How can i achieve this?
First - you make sure all fields are set to optional in the schema, otherwise this will never work.
Second - You save.
When an optional field has no value, it will have no XML representation. If you have a schema that defines a component like this:
Field1
Field2
Field3
When all fields are optional and you save a value in Field 2, Tridion will store the following:
<Content xmlns="yourNamespace"><Field2>SomeValue</Field2></Content>
If one of your fields is not mandatory, then you'll have to provide a value. If you're using the CoreService then you can use ReadSchemaFields class to get the fields and some information about them - what type, mandatory/optional, etc.
Looking at your question/requirement to understand what you're exactly looking for, so we can answer the best possible and relevant.
Are you asking for "How can you write a generic code for component creation using core service?" instead of creating a component with a specific schema knowing all the fields upfront.
If that is what you are looking for, here is what you need to do:
You need to read the schema fields with CoreService (since you know the schema URI)
Now you know what type of fields (embedded/component link etc) you need to create content for
use the links pointed by "Puf" in his answer.
Please note that, if the field is marked as required in Tridion Schema you must have to fill a value and it has to match the field type defined in schema.
Reading schema fields via Core Service sample code can be found here
Updating a Component's field through the Core Service is already answered here: Updating Components using the Core Service in SDL Tridion 2011
That post points to a helper class you can find here: Updating Components using the Core Service in SDL Tridion 2011
If those don't help you in creating a Component, I suggest you post your code instead of asking us to write it for you.
We ask about use case, because code to fill in specific fields for a specific schema only works in one environment. Code that can automatically determine fields is re-usable.
If the use case is for an Tridion setup that has Inline Editing (Experience Manager or SiteEdit), then the correct approach is content/component types. These define a reference component with "junk defaults," instructions to the author, and even save location context.
If the use case is to allow authors the ability to create dummy components, this is out-of-the box with:
CTRL+C
CTRL+V
One-time setup required to create a "reference component." Of course we can mimic this behavior (in case "Copy of Untitled" isn't an appropriate name) by copying items with the core service.
In that case, I'll also do a copy--see a general solution for creating Tridion items using the Core Service.
Fields that require a default can have an actual default in the schema.
"Junk values" don't help authors much, always consider good defaults such as an appropriate selection or instructions in the case of fields (maybe). A 10 second change costs development practically nothing, but impacts all future components and the authors that create them.
Recently, I discovered that the "Web.Config" file contains an <appSettings> section which seemed good for storing one's Application Settings. Heck, it even has a programmatic way to access the file thru a standard System library. So being all clever, I wrote an Interface to access it and then a Concrete implementation of the interface, shown here:
public interface IAppSettings
{
IEnumerable<string> GetValues(string componentName, string settingName);
IEnumerable<KeyValuePair<string, string>> GetValuePairs(string componentName, string settingName);
void SetValues(string componentName, string settingName, IEnumerable<string> valueList, bool append);
void SetValuePairs(string componentName, string settingName, IEnumerable<KeyValuePair<string, string>> pairList, bool append);
}
Then I came to discover that saving settings back to "web.config" while the application is running causes the entire application to re-start. This seems completely unreasonable to me because if I'm writing back to web.config a lot and the application is restarting each time, then things like HttpRuntime.Cache get completely emptied effectively making my Cache useless because it's constantly emptying and repopulating.
So I'm wondering: Where should I store my Application Settings?
Is there a good solution out there for this so that I don't have to roll my own?
EDIT:
Okay, thanks to everyone who suggested using a DB and a potential table schema. I think I'm going to go with the following schema:
settings:
index NUMBER NOT NULL AUTO_INCREMENT <== Primary Key
component NVARCHAR(255) NOT NULL
setting NVARCHAR(255) NOT NULL
key NVARCHAR(255)
value NVARCHAR(255) NOT NULL
Though I don't think I'll make the "setting" the P-Key, but use an Auto-Incr Index instead. This way if I have an application that needs to mail something to multiple managers, I can store many:
index component setting value
1 RequestModule ManagerEmail manager1#someplace
2 RequestModule ManagerEmail manager2#someplace
And then I can use:
IEnumerable<string> GetValues(string componentName, string settingName);
And it will return a list of email addresses, rather than just a single value.
Does this make sense?
web.config is generally used for read-only settings, ie. the settings set during deployment of the application by the system administrator.
If you want to read and write the settings, the most obvious way is to use the database. By the way, this has an advantage: an application can be hosted on several servers and will still read and write the settings correctly,
You can also implement your custom storage for the settings, but it will be probably more difficult to implement and not much faster.
To answer your second question, the structure of your database depends on the type of settings you want to store.
If you need to store heterogeneous unique entries like this:
Mail address of an administrator,
Maximum number of entries to display on home page of the website,
Text to display on "About us" page,
Boolean value indicating whether public comments are enabled or not,
then you have to use varchars or other more or less friendly types as keys to identify the entries (rather than to refer to them by their index).
On the other hand, if your purpose is to store the mail addresses of several managers, you should create a Manager table containing their mail addresses, names, datetime of their last connection, etc.
You really shouldn't mix both. In theory, you can refer to the entry in settings by component/setting pair. In practice, it makes things harder and creates a bunch of problems:
What if, further, you will need, for every manager, to store a boolean value indicating whether she/he wants to receive alerts from you? With your current structure, this will be impossible.
Since the same setting can have multiple values, how do you intend to handle the settings which must be unique? For example, there must be only a single value of text to display on "About us" page. What if there are two values stored in database?
Storing settings in web.config is useful because it makes it easy to have different settings in different environments. However, as you say, this is no use if you are likely to want to change the settings in a live environment.
A simple database table is the most useful way to do this if you need to change the values.
eg.
create table Settings
(Name varchar(50) primary key,
Value varchar(50))
If you're using SQL Server, you can set to the Value column to be sql_variant which will allow you to store a variety of datatypes.
It is meant for application settings, but not settings that are meant to be dynamically changed during runtime. Rather, it is for settings that change only occasionally, and where you would expect (and even desire) an app restart when they change.
For more ephemeral settings, you may want to just use a simple database system - even a flat file/XML in the App_Data dir can work, if your app doesn't use a database otherwise.
Yes.Changing the web.config will reset the application.I usually maintain a settings table to store key-value pairs for the settings and access it from there.
SETTINGS
SETTING_NAME VARCHAR(100)PRIMARY KEY
SETTING_VALUE VARCHAR(100)
Then write a class which can Insert,Delete,Update values to this table.
Ex Data for the SETTINGS table
SETTING_NAME SETTING_VALUE
AdminEmail admin#mysite.com
ErrorTrackingEmail errors#mysite.com
I usually add a "type" field to my settings table so that I only retrieve the group of settings needed this works for me as a way of grouping like settings and retrieving them at once.
Create a key-valued table like this:
settings:
name NVARCHAR(255) PRIMARY KEY
value NVARCHAR(255) NOT NULL
First of all, it's not unreasonable at all when you consider what information is supposed to be stored in the web.config file. When you change things like assembly information, connection strings, etc., your application needs to stop and reload the values to run with those settings.
If you're storing application wide settings, then you can create a Settings table in your database or even use a separate text file to store the settings.
If you're talking about storing per-user settings, you shoul check out ASP.NET Profile Properties.
Application-wide settings should certainly be stored in this section of the web.config file, as it prevents hard-coding values which may change over time. There's no need to read them out using your own code, as there's a built-in method: use the System.Configuration.ConfigurationManager.AppSettings array to retrieve them (you'll need to add a reference to the System.Configuration assembly in your project). You can edit AppSettings through the ASP.NET Web Site Administration Tool, too (Project menu -> ASP.NET Configuration).
For values which you envisage changing more often and while the site is up and running, it's reasonable to use an XML file, lightweight database (such as SQLite or SQL Server Compact) or even a text file for these settings.
If you need to save settings, you can always save them in a custom configuration file.
I did just that a while back, and I have the code available to do it here.
I have a document based on a xml structure that I have stored in a CouchDB database.
Some of the keys contains namespaces and are on the form "namespace:key":
{"mykey": {"nested:key": "nested value"}}
In the map function, I want to emit the nested value as a key, but the colon inside the name makes it hard...
emit(doc.mykey.nested:key, doc) <-- will not work.
Does anyone know how this can be solved?
A hint that its all just JSON and JavaScript got me some new ideas for searching.
It may be that colon in json keys ain't valid, but I found a way. By looking at the doc object as an hash, I can access my value in the following manner:
Doc.mykey['nested:key']
It works - for now...
That's because Couch is a JSON based document DB, and doc.mykey.nested:key is not a valid JSON identifier. JSON identifiers must match JavaScripts identifiers, and : is not a valid identifier character.
So, the simple answer is: "No, this won't and can't work". You need to change your identifiers.
Actually, I should qualify that.
Couch can use pretty much ANYTHING for it's views et al, and, in theory, works with any payload. But out of the box, it's just JavaScript and JSON.