Using Netscape library for performing LDAP search operation and getting limited result upto 10000 when range is provided (0-*) - ldap

I am using Netscape library for performing search operation on microsoft ADS/ADAM Ldap server
Following is the snippet I am using:
LDAPConnection connection=new LDAPConnection();
connection.connect("xx.xx.xx.xx", 389);
connection.authenticate( "CN=xx,CN=xx,DC=xx,DC=xx,DC=xx", "xxxx");
String[] attr= { "member;range=0-*" };
LDAPSearchResults resultSet = connection.search("CN=UsersGroup,CN=Builtin,DC=xx,DC=xx,DC=xx", 2, "(&(objectclass=group))", attr,false);
API is returning only 10000 records for "member" multivalued attribute.
MaxValRange value is set to 50000 on server.
Is there any way I can get more than 10K records in single search?

AFIK, besides modifying the MaxValRange, you need to override the upper-limits introduced in Windows Server 2008/R2 and restore the old-style (no upper limit enforced behavior for LDAP Query Policy in Windows Server 2003), modify the dSHeuristic attribute in Active Directory.
And of course you could use the Ranging OID.
We did, sometime ago, create some Example Java code to make the process easier.

Related

Lucee <cfadmin> does not correctly store connectionString property when executing an "updateDatasource" operation

I'm hoping someone can shed some light on this issue. I'm attempting to programmatically add datasources to the Lucee Server context (ie. not on a per-application basis, but rather datasources that are made available to all web contexts on the server). The following call to the tag to create the datasource or later update the same datasource results in the connectionString never being saved correctly.
NOTE: "updateDatasource" will create a datasource if it doesn't already exist.
Host Environment: Windows Server 2019 running Lucee 5.3.8.206 on OpenJDK17.
Database Environment: Windows Server 2019 running SQL Server 2019.
<cfadmin
action="updateDatasource"
type="server"
password="F4K31234"
bundlename="org.lucee.mssql"
bundleversion="8.4.1.jre8"
classname="com.microsoft.sqlserver.jdbc.SQLServerDriver"
dsn="my_new_datasource"
name="my_new_datasource"
newName="my_new_datasource"
connectionString="jdbc:sqlserver://SQLSERVERNAME\MSSQLSERVER2019;DATABASENAME=my_database;sendStringParametersAsUnicode=true;SelectMethod=direct"
dbusername="Temp1234"
dbpassword="F4K31234"
connectionLimit="100"
alwaysSetTimeout="true"
validate="false"
allowed_select="true"
allowed_insert="true"
allowed_update="true"
allowed_delete="true"
allowed_create="true"
allowed_revoke="true"
allowed_alter="true"
allowed_grant="true"
clob="true"
lineTimeout="60">
Every time this operation is attempted, the Connection String is stored as "my_database". In other words, it appears to ignore the string provided in the connectionString attribute and instead stores the database name for the datasource connection string.
These settings are exactly what I use when manually setting up a datasource in the Lucee Server administrative area (minus the obvious fake username, passwords, server names, and database names).
Before I go about filing a bug, I wanted to be sure I'm not missing something here. I appreciate any insight!

Difference between with and without sudo() in Odoo

What is different between:
test = self.env['my.example'].sudo().create({'id':1, 'name': 'test'})
test = self.env['my.example'].create({'id':1, 'name': 'test'})
All example work, but what is the advantages when using sudo()?
Odoo 8–12
Calling sudo() (with no parameters) before calling create() will return the recordset with an updated environment with the admin (superuser) user ID set. This means that further method calls on your recordset will use the admin user and as a result bypass access rights/record rules checks [source]. sudo() also takes an optional parameter user which is the ID of the user (res.users) which will be used in the environment (SUPERUSER_ID is the default).
When not using sudo(), if the user who calls your method does not have create permissions on my.example model, then calling create will fail with an AccessError.
Because access rights/record rules are not applied for the superuser, sudo() should be used with caution. Also, it can have some undesired effects, eg. mixing records from different companies in multi-company environments, additional refetching due to cache invalidation (see section Environment swapping in Model Reference).
Odoo 13+
Starting with Odoo 13, calling sudo(flag) will return the recordset in a environment with superuser mode enabled or disabled, depending if flag is True or False, respectively. The superuser mode does not change the current user, and simply bypasses access rights checks. Use with_user(user) to actually switch users.
You can check the comments on sudo in Odoo code at odoo -> models.py -> def sudo().
Returns a new version of this recordset attached to the provided
user.
By default this returns a ``SUPERUSER`` recordset, where access
control and record rules are bypassed.
It is same as:
from odoo import api, SUPERUSER_ID
env = api.Environment(cr, SUPERUSER_ID, {})
In this example we pass SUPERUSER_ID in place of uid at the time of creating a Enviroment.
If you are not use Sudo() then the current user need permission to
create a given object.
.. note::
Using ``sudo`` could cause data access to cross the
boundaries of record rules, possibly mixing records that
are meant to be isolated (e.g. records from different
companies in multi-company environments).
It may lead to un-intuitive results in methods which select one
record among many - for example getting the default company, or
selecting a Bill of Materials.
.. note::
Because the record rules and access control will have to be
re-evaluated, the new recordset will not benefit from the current
environment's data cache, so later data access may incur extra
delays while re-fetching from the database.
The returned recordset has the same prefetch object as ``self``.

Alfresco Lucene search results via Java API differ from results in Nodebrowser

I use Alfresco 4.1 with Lucene enabled. I have a folder of type 'myfoldertype' and named 'one two'. Tokenization on the name is (by default) enabled.
I search by name on a specific type of folder, via my own Java backed webscript. Like this:
SearchParameters sp = new SearchParameters();
sp.addStore(StoreRef.STORE_REF_WORKSPACE_SPACESSTORE);
sp.setLanguage(SearchService.LANGUAGE_LUCENE);
sp.setQuery("TYPE:\"mymodel:myfoldertype\" AND #cm\\:name:*one*"
I run this query in the authentication context of a user with AuthenticationUtil.runas(). The user has read-access to this folder.
Now, the resultset contains 0 results.
But if I copy/paste the query from the log into the Nodebrowser (in Lucene mode), it DOES return the expected folder.
What could cause this difference? Obviously I would like to get the expected folder in the resultset in my webscript as well.
In Java you're not escaping the \ properly
So #cm\:name:*one* should be #cm\\:name:*one*
The cause was that my webscript was running under the (JVM default) locale of en-US, but the Nodebrowser was running under the UI locale nl-NL. The cm:name property is of datatype d:text, which has different analyzers for en (AlfrescoStandardAnalyzer) and nl (DutchAnalyzer).
I changed the webscript to use the nl locale and now it returns the same results as the Nodebrowser:
import org.springframework.extensions.surf.util.I18NUtil;
...
I18NUtil.setLocale(new Locale("nl"));
return searchService.query(sp);

Determine request Uri from WCF Data Services LINQ query for FirstOrDefault against Azure without executing it?

Problem
I would like to trace the Uri that will be generated by a LINQ query executed against a Microsoft.WindowsAzure.StorageClient.TableServiceContext object. TableServiceContext just extends System.Data.Services.Client.DataServiceContext with a couple of properties.
The issue I am having is that the query executes fine against our Azure Table Storage instance when we run the web role on a dev machine in debug mode (we are connecting to Azure storage in the cloud not using Dev Storage). I can get the resulting query Uri using Fiddler or just hovering over the statement in the debugger.
However, when we deploy the web role to Azure the query fails against the exact same Azure Table Storage source with a ResourceNotFound DataServiceClientException. We have had ResoureNotFound errors before that dealt with the behavior of FirstOrDefault() on empty tables. This is not the problem here.
As one approach to the problem, I wanted to compare the query Uri that is being generated when the web role is deployed versus when it is running on a dev machine.
Question
Does anyone know a way to get the query Uri for the query that will be sent when the FirstOrDefault() method is called. I know that you can call ToString() on the IQueryable returned from the TableServiceContext but my concern is that when FirstOrDefault() is called the Uri might be further optimized and ToString() on IQueryable might not be what is ultimately sent to the server when FirstOrDefault() is called.
If someone has another approach to the problem I am open to suggestions. It seems to be a general problem with LINQ when trying to determine what will happen when the expression tree is finally evaluated. I am open to suggestions here as well because my LINQ skills could use some improvement.
Sample Code
public void AddSomething(string ProjectID, string Username) {
TableServiceContext context = new TableServiceContext();
var qry = context.Somethings.Where(m => m.RowKey == Username
&& m.PartitionKey == ProjectID);
System.Diagnostics.Trace.TraceInformation(qry.ToString());
// ^ Here I would like to trace the Uri that will be generated
// and sent to the server when the qry.FirstOrDefault() call below is executed.
if (qry.FirstOrDefault() == null) {
// ^ This statement generates an error when the web role is running
// in the fabric
...
}
}
Edit Update and Answer
Steve provided the write answer. Our problem was as exactly described in this post which describes an issue with PartitionKey/RowKey ordering in Single Entity query which was fixed with an update to the Azure OS. This explains the discrepancy between our dev machines and when the web role was deployed to Azure.
When I indicated we had dealt with the ResourceNotFound issue before in our existence checks, we had dealt with it in two ways in our code. One way was using exception handling to deal with the ResourceNotFound error the other way was to put the RowKey first in the LINQ query (as some MS people had indicated was appropriate).
It turns out we have several places where the RowKey was first instead of using the exception handling. We will address this by refactoring our code to target .NET 4 and using the .IgnoreResourceNotFoundException = true property of theTableServiceContext .
Lesson learned (more than once): Don't depend on quirky undocumented behavior.
Aside
We were able to get the query Uri's. They did turn out to be different (as indicated they would be in the blog post). Here are the results:
Query Uri from Dev Fabric
`https://ourproject.table.core.windows.net/Somethings()?$filter=(RowKey eq 'test19#gmail.com') and (PartitionKey eq '41e0c1ae-e74d-458e-8a93-d2972d9ea53c')
Query Uri from Azure Fabric
`https://ourproject.table.core.windows.net/Somethings(RowKey='test19#gmail.com',PartitionKey='41e0c1ae-e74d-458e-8a93-d2972d9ea53c')
I can do one better... I think I know what the problem is. :)
See http://blogs.msdn.com/b/windowsazurestorage/archive/2010/07/26/how-wcf-data-service-changes-in-os-1-4-affects-windows-azure-table-clients.aspx.
Specifically, it used to be the case (in previous Guest OS builds) that if you wrote the query as you did (with the RowKey predicate before the PartitionKey predicate), it resulted in a filter query (while the reverse, PartitionKey preceding RowKey) resulted in the kind of query that raises an exception if the result set is empty.
I think the right fix for you (as indicated in the above blog post) is to set the IgnoreResourceNotFoundException to true on your context.

WebSharingAppDemo-CEProviderEndToEnd Queries peerProvider for NeedsScope before any files are batched to the server. This seems out of order?

I'm building an application based on the WebSharingAppDemo-CEProviderEndToEnd. When I deploy the server portion on a server, the code gives the error "The path is not valid. Check the directory for the database." during the call to NeedsScope() in the CeWebSyncService.cs file.
Obviously the server can't access the client's sdf but what is supposed to happen to make this work? The app uses batching to send the data and the batches have to be marshalled across to the temp directory but this problem is occurring before any files have been batched over. There is nothing for the server to look at to determine whether the peerProivider needs scope. What am I missing?
public bool NeedsScope()
{
Log("NeedsSchema: {0}", this.peerProvider.Connection.ConnectionString);
SqlCeSyncScopeProvisioning prov = new SqlCeSyncScopeProvisioning();
return !prov.ScopeExists(this.peerProvider.ScopeName, (SqlCeConnection)this.peerProvider.Connection);
}
I noticed that the sample was making use of a proxy to speak w/ the CE file but a provider (not a proxy) to speak w/ the sql server.
I switched it so there is a proxy to reach the SQL server and a provider to access the CE file.
That seems to work for me.
stats = synchronizationHelper.SynchronizeProviders(srcProvider, destinationProxy);
vs.
SyncOperationStatistics stats = syncHelper.SynchronizeProviders(srcProxy, destinationProvider);