I have written a program that reads a webservice, retrieving user data, and then is supposed to push that data to ActiveDirectory, thus updating the user's title, address, phone numbers, etc.
The problem is that when I perform the search using the Unboundid Connection class the requested attributes are not returned. Below is the search code:
SearchResult result = connection.search( properties.getProperty("ldap.search.baseDN"),
SearchScope.SUB, "(cn=" + userId + ")",
"personalTitle", "department", "company", "manager", "telephoneNumber",
"streetAddress", "I", "st", "postalCode", "c", "pager", "mobile",
"fax", "cn");
The above code locates the desired user and the cn attribute is returned as expected, but the other attributes all fail to return. If I connect to AD using JXplorer using the same connection credentials, I'm able to see all the desired attributes exist, but are simply not being returned.
I have tried substituting SearchRequest.ALL_OPERATIONAL_ATTRIBUTES, SearchRequest.ALL_USER_ATTRIBUTES and SearchRequest.REQUEST_ATTRS_DEFAULT rather than listing the fields explicitly, but with no success.
I have also looked at the 'Schema' object returned from 'connection.getSchema()' and can see that personalTitle should exist:
connection.getSchema().getAttributeType("personalTitle")
The above code returns:
1.2.840.113556.1.2.615 NAME 'personalTitle' SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE
So maybe this is a user permission issue? Has anyone experienced this and know how to resolve it?
Thanks,
Mike
LDAP search result entries only include attributes that actually have values, so the behavior you are seeing from the UnboundID LDAP SDK is appropriate and correct. Even if you explicitly request a particular attribute, that attribute will only be included in the entry if it has one or more values.
I think that you're confused by JXplorer because it's reading the schema to determine what attributes could possibly be included in the entry based on its object classes and is showing them to you so that you can set values for those attributes in the editor. But that doesn't mean that the entry returned by the server actually includes any information about those attributes.
To verify this, you can use the ldap-debugger tool provided with the LDAP SDK to see the actual LDAP communication that occurs. Just run a command like:
tools/ldap-debugger --hostname {directory-server-address} \
--port {directory-server-port} --listenPort {listen-port}
This will create a very simple LDAP proxy server that decodes all requests and responses that pass through it. To use it, simply point JXplorer at the specified listen-port. You will see that when JXplorer retrieves the entry, the entry returned by the server will only contain attributes that actually have values.
If you want to figure out what all the possible attributes are that you can include in a given entry, then use the LDAPConnection.getSchema method to retrieve the server schema, then Schema.getObjectClass for each of the object classes in the target entry, and finally use the ObjectClassDefinition.getRequiredAttributes and ObjectClassDefinition.getOptionalAttributes methods to see what attribute types must and may be used in entries with that object class.
Related
I'm using Spring to build a simple Web app. At the front end I have a REST api, which has a PUT method like this: /api/v1/apple/{id}
When the call comes in to this endpoint, the body is deserialised to an Apple.
In the spec for PUT it says: "The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI."
So if apple 21 exists in the DB (and is therefore reachable at /api/v1/apple/21), it should be replaced with the one in the request.
But if it doesn't, a new one should be created, as per the apple in the request, with primary key 21 and URI /api/v1/apple/21.
The problem is that the ReactiveCrudRepository seems not to support this.
According to the release notes, since spring-data r2dbc 1.0.0, if you call save() and the row doesn't exist in the database, it throws a TransientDataAccessException. I see the following:
Failed to updated table [apples]. Row with Id [21] does not exist.
org.springframework.dao.TransientDataAccessResourceException: Failed to updated table [apples]. Row with Id [21] does not exist.
at app//org.springframework.data.r2dbc.core.R2dbcEntityTemplate.lambda$doUpdate$14(R2dbcEntityTemplate.java:707)
.....
So if I supply an ID for my new Apple, I can't create it - at least not using ReactiveCrudRepository. If I remove the ID from the POJO first, it will create it, but with an assigned ID - in other words calling PUT /api/v1/apple/21 will result in creation of an apple, but with some other id (not 21).
What am I missing here? There appear to be no alternatives to the save() method which behave the way I need.
I have a field that I can insert a certain name and find the user with the correspondent name,that was developed in react.
My code works when that name is like "test", but if the name is like "this test" (if the name has a space on it), my backend receives the name in this format ("this%20test") and when I am searching for that name on the database, the entry returns null.
How can I solve this? I want to solve this on my frontend because I think it´s the best option.
Any parameters passed as query params will be url-encoded and passed to your backend.
You need to url decode parameters in your backend.
See this to url decode in java
https://stackoverflow.com/a/6138183/3295987
In Neo4J, I want to use the bolt protocol.
I installed the 3.1 version of Neo4J.
I my Java project, that already works well with normal HTTP Rest API of Neo4J, I integrate with Maven the needed drivers and achieve to perform request with BOLT.
The problem is everywhere you make a search about bolt they give example like this one :
MATCH (a:Product) return a.name
But I don't want the name, I want all the data of all product, what ever i know or not before what are these columns, like here:
MATCH (a:Product) return * --> here I retrieve only the ids of nodes
I found there https://github.com/neo4j-contrib/neo4j-jdbc/tree/master/neo4j-jdbc-bolt we can "flatten" the result but it seems to not work or I didn't understand how it works:
GraphDatabase.driver( "bolt://localhost:7687/?flatten=-1", AuthTokens.basic( "neo4j", "......." ) );
I put the ?flatten=-1 at the end of my connection address... but that changed nothing.
Anyone can help? Or confirm it's not possible or not working ?
Thanks
Ok I understood my error, I didn’t dig enough in the object returned. So used to have a JSON formatted response, I didn’t see that I have to search in the StatementResult object to find the wanted object with its properties. In fact Eclipse in the “expressions” shows “in fly” only the ids, but inside the object data are there.
Record oneRecord = rs.next();
String src = oneRecord.get("m").get("source");
That way I can reconstruct my object
The situation:
I'm actually reading contact information from an Ldap source within a Java application. The found SearchResult contains all values I want, no trouble with that.
Once the SearchResult is available, I need to read its attributes - which attributes to read, is specified by the user in a config file.
The problem, explained on an example:
A user specifies to read the property 'stateOrProvinceName'. The Ldap handles this as 'st'. The returned Searchresult will contain a key=>value pair with 'st' as key. If I look up 'stateOrProvinceName' this will of cource not be found. I want that 'st' key - but I do not want to manually code a mappnig of alternative Ldap-Field names. The relevant code part:
Attributes ldapAttributes = foundContact.getAttributes();
Attribute wantedAttribute = ldapAttributes.get(ldapFieldName);
Explanation: 'foundContact' is the SearchResult, I store its Attributes in 'ldapAttributes'. The 'ldapFieldName' is the name, the user specified in the config file (like 'stateOrProvinceName'), I try to get this attribute and store it in 'wantedAttribute'. If 'stateOrProvinceName' is not contained, 'wantedAttribute' is of course null. But since 'st' exists, I do not want this to be null ;)
The question:
is there some 'easy' way to retrieve a list of all alternative names, given one name of an attribute?
Thanks for your time!
The rfc'ed approach for that is to locate the attribute definition in your entry's subschemaSubentry referenced schema definition. (p32 in RFC 4512)
E.g. OpenLDAP stores this information in cn=Subschema. Unfortunately this entry uses the attribute definition format which you first have to parse by yourself:
attributetype ( 2.5.4.8
NAME ( 'st' 'stateOrProvinceName' )
DESC 'RFC2256: state or province which this object resides in'
SUP name )
Iirc/maybe UnboundID's LDAP SDK has now a parser for this purspose.
In the Rally REST Java API (1.40), how can I create a QueryRequest to find a specific DELETED item by FormattedID.
QueryRequest queryRequest = new QueryRequest("recyclebinentry");
I see in an unrestricted query ( e.g. no filter set ), the value for the FormattedID is returned in the "ID" property, but using that property or FormattedID in a query results in the queryResponse.wasSuccessful() being false.
Unfortunately, the Recycle Bin offers only very limited query-ability. As you've found, FormattedID is not accepted, nor are DeletedBy, Name, Type, or other useful identifying fields. The best you can really do is filter by DeletionDate. For example (DeletionDate >= "2013-03-01T15:00:00Z") to narrow your results. Then manually search on the client-side.
I'd recommend posting this as a Feature Request to Rally Ideas, since this is a commonly requested item.