Geoserver : Implementing a RESTful Service

I was following this tutorial
http://docs.geoserver.org/stable/en/developer/programming-guide/rest-ser...

to add a rest service endpoint to geoserver 2.1.1 and hit a few snags:
1. must modify restconfig applicationContext.xml
and
add the "hello" bean
and
routes mapping
(by "modify" i mean re-build the module, and the web/app module)

2. "txt" extension does not map to any MediaType, hence if we try
http://localhost:8080/geoserver/rest/hello.txt
we will get HTTP Error 500.

3. therefore we use hello.json, so we have to add
formats.add(new StringFormat( MediaType.APPLICATION_JSON ));
into HelloResource.java

4. we can go to
http://localhost:8080/geoserver/rest/hello.json
and now can successfully get the json file

Outlook 2007 and rss feed

Opening rss feed in Outlook from Firefox makes Outlook 2007 convert the url into lowercase, so if you have a camelCase http param, then it wouldn't work.

Solution is to have all lowercase http get param as your feed url.

Using Image as a submit button

name="downloadFormPOST"
method="post"
action="http://theurl"
>

function openElt() {

var jsonRequest =
{
"template": {
"id": [currentQueryParams.identifier],
"class": "com.erdas.rsp.babel.model.CatalogItem"
},
"maxresults": -1,
"profile": "eac-brief"
};

var AjaxObject = {

handleSuccess:function(o) {
var xmlToDownload = o.responseText;
var downloadForm = window.document.forms['downloadFormPOST'];

var xmlInput = document.getElementById("xmlToDownload");
xmlInput.value = xmlToDownload;
downloadForm.submit();

},


handleFailure:function(o) {
},


startRequest:function() {

var jsonString = YAHOO.lang.JSON.stringify(jsonRequest);
YAHOO.util.Connect.initHeader('Accept', 'application/x-vnd.elt+xml; charset=utf-8', true);
YAHOO.util.Connect.asyncRequest('POST',
'http://<%=request.getServerName()%>:<%=request.getServerPort()%>/erdas-apollo/catalog/content/search',
callback,
jsonString
);
}

};


var callback = {
success:AjaxObject.handleSuccess,
failure:AjaxObject.handleFailure,
scope: AjaxObject
};


AjaxObject.startRequest();
}


<%
String xmlToDownload = request.getParameter("xmlToDownload");
if( xmlToDownload != null && !"".equals(xmlToDownload) ) {

response.setContentType("application/x-vnd.elt+xml; charset=utf-8");
String outputExtension = "elt";
String nowStr = new SimpleDateFormat("yyyy_MM_dd-HH_mm_ss").format(new Date());
response.setHeader("Content-Disposition", "attachment; filename=results-" + nowStr + "." + outputExtension);
PrintWriter writer = response.getWriter();
writer.println(xmlToDownload);
}
%>

JBoss NTLM Auth + (Maybe Drupal NTLM Auth)

http://www.ioplex.com/jespa.html for NTLMv2 (http://jcifs.samba.org/ only support NTLMv1)

http://code.google.com/p/jespa-spring/ (for Spring-Framework NTLM), this is for spring-security-3.x

I modified jespa-spring for spring-security-2.x in http://github.com/lydonchandra/jespa-spring2 (just remember to create src/main/java directory and put the source files into it if I haven't done it)

To find domain controller:

echo %LOGONSERVER%

Drupal NTLM auth (this might be NTLMv1)

http://drupal.org/node/44718

Drupal + OpenLayer + Apollo

1. At Administer > Site building > Modules, enable the PHP filter module.

2. <script src="http://localhost:8080/apollo-client/OpenLayers.js"></script>

<?php
drupal_add_js(
'$(document).ready(function(){

var map = new OpenLayers.Map("myWorldMap");

var wms = new OpenLayers.Layer.WMS(
"OpenLayers WMS",
"http://don_laptop:8080/erdas-apollo/vector/WORLDWIDE",
{layers: "cntry98gen02"}
);

map.addLayers([wms]);
map.zoomToMaxExtent();
});',
'inline'
);
?>

<div id="myWorldMap" style="width: 600px; height: 300px">
</div>

3. Also I needed to avoid cross-domain error because I have AJAX request going from localhost:8082 (drupal) to localhost:8080 (erdas-apollo)

ProxyRequests Off

ProxyPass /apollo-json http://don_laptop:8080/erdas-apollo/catalog/content/search.json

ProxyPassReverse /apollo-json http://don_laptop:8080/erdas-apollo/catalog/content/search.json

Flushing JAAS aut cache

To disable caching you need to set the DefaultCacheTimeout to 0:
in jboss-service.xml,
<attribute name="DefaultCacheTimeout">0</attribute>

LDAP JBoss authentication and authorization

<policy>

<application-policy name="apollo">
<authentication>
<login-module code="org.jboss.security.auth.spi.LdapExtLoginModule"
flag="required">
<module-option name="debug">true</module-option>
<module-option name="java.naming.provider.url">ldap://localhost:389/</module-option>
<module-option name="java.naming.security.authentication">simple</module-option>
<module-option name="bindDN">CN=admin,CN=Users,CN=donLaptop,DC=don,DC=com</module-option>
<module-option name="bindCredential">secretpassword</module-option>
<module-option name="baseCtxDN">CN=Users,CN=donLaptop,DC=don,DC=com</module-option>
<!-- <module-option name="baseFilter">(sAMAccountName={0})</module-option> -->
<module-option name="baseFilter">(CN={0})</module-option>
<module-option name="rolesCtxDN">CN=Users,CN=donLaptop,DC=don,DC=com</module-option>
<module-option name="roleFilter">(member={1})</module-option>
<!-- module-option name="roleFilter">(sAMAccountName={0})</module-option -->
<module-option name="roleAttributeID">memberOf</module-option>
<module-option name="roleAttributeIsDN">true</module-option>
<module-option name="roleNameAttributeID">CN</module-option>
<!-- if a default role is needed to be applied to all accounts, it can be achieved by uncommenting the below -->
<!-- module-option name="defaultRole">esp_consumer</module-option -->
<module-option name="roleRecursion">2</module-option>
<module-option name="searchScope">SUBTREE_SCOPE</module-option>
<!-- An empty password is treated as an anonymous login by some ldap servers and this may not be a desirable feature.
Set this to false to reject empty passwords, true to have the ldap server validate the empty password. The default is true. -->
<module-option name="allowEmptyPasswords">false</module-option>
</login-module>
<!--
<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
flag = "required">
<module-option name="usersProperties">props/apollo-users.properties</module-option>
<module-option name="rolesProperties">props/apollo-roles.properties</module-option>
</login-module>
-->
<!-- Need to include ClientLoginModule to propagate caller's subject and security context
Add this line to your login-config.xml to include the ClientLoginModule propogation -->
<login-module code="org.jboss.security.ClientLoginModule" flag="required">
<module-option name="restore-login-identity">true</module-option>
<module-option name="multi-threaded">true</module-option>
</login-module>
</authentication>
</application-policy>
</policy>



#
#############################################################################
#
# The nms-ldap.properties file is referenced by login-config.xml and is used
# by the NmsLdapLoginModule. This file controls whether LDAP access to a
# directory service is enabled for user passwords (and, optionally, user
# roles), and what parameter values are used.
#
# Contact your directory service administrator to determine the correct
# values to use in this file.
#
# This file is accessed before each attempt to sign in to the NNMi console,
# so its contents may be modified without restarting ovjboss.
#
# Whole line comments are allowed when start with a "#", but "#" characters
# at the end of a line are considered part of the value:
# paramName=paramValue # This string is part of paramName
#
# Any error messages from incorrect configuration of this file are logged to
# /log/nnm/jbossServer.log.
#
# While testing changes to this file, be sure to use "File:Sign Out",
# instead of just closing the browser, to ensure you are fully signed
# out. Doing so prevents the browser from using cached credentials.
#
# For detailed information about configuring LDAP access to a directory
# service, see the HP Network Node Manager i-series Software Deployment and
# Migration Guide.
#
#############################################################################
#


#
# java.naming.provider.url:
#
# The URL for accessing the directory service.
#
# This parameter must be set to enable LDAP access to a directory service.
# If this parameter is not set in this file, LDAP queries are not
# attempted during user sign in.
#
# The value is in the form "ldap://ldap.myco.com" or
# "ldap://ldap.myco.com:636" (which is the same as
# "ldaps://ldap.myco.com:636").
#
# If a port is specified in the URL, the specified port overrides the
# default. If unspecified, port 389 is used for non-SSL connections, or
# port 636 is used for SSL connections (as defined by
# java.naming.security.protocol).
#
# To disable login attempts through LDAP, comment out this parameter.
#
# It is recommended that all User Accounts be deleted from NNMi after
# enabling this feature, and that all Principals be deleted from NNMi after
# disabling this feature. Doing so prevents accidental access through
# previously configured values.
#
#java.naming.provider.url=ldap://ldap.myco.com:389/


#
# java.naming.security.protocol:
#
# If this parameter is set to "ssl", NNMi uses the Secure Sockets Layer
# protocol for communications with the directory service.
#
# Enable SSL if you see an error in the jbossServer.log file that is
# similar to:
# javax.naming.AuthenticationNotSupportedException:
# [LDAP: error code 13 - confidentiality required]
#
# To enable SSL, import your company's trust store certificate into the
# /shared/nnm/certificates/nnm.truststore, with a command such
# as (for UNIX):
#
# /opt/OV/nonOV/jdk/nnm/bin/keytool -storepass ovpass -import \
# -file my_certificate_authority_cert.txt -alias 'nnmi_ldap' \
# -keystore /var/opt/OV/shared/nnm/certificates/nnm.truststore
#
# where my_certificate_authority_cert.txt is a file containing the
# certificate required by the directory service for SSL communication.
#
#java.naming.security.protocol=ssl


#
# bindDN:
# bindCredential:
#
# By default, the request to validate a username and password uses
# anonymous login. However some directory services (such as
# Active Directory Services) disallow anonymous access. Use this to
# provide credentials to the directory service.
# Note that as with any entry in this file, if you want to
# specify a backslash ('\'), it must be escaped as '\\'
#
#bindDN=MyDomain\\Some User Name
#bindCredential=someUserPassword


#############################################################################
#
# The distinguished name that is passed to the directory service for
# authenticating a user is the concatenation of the baseFilter value and the
# baseCtxDN value.
#
# For example, if baseFilter is set to "uid={0}", baseCtxDN is set to
# "ou=People,o=myco.com", and a user signs in to NNMi as "john.doe", then the
# string passed to the directory service is:
# uid=john.doe,ou=People,o=myco.com
#
#############################################################################


#
# baseCtxDN:
#
# Required. The user name search context, which is the fixed portion of the
# distinguished name for the user search.
#
# For an Active Directory server, this might be a value like:
# baseCtxDN=CN=Users,DC=mycompany,DC=com
#
baseCtxDN=ou=People,o=myco.com


#
# baseFilter:
#
# Required. The variable portion of the distinguished name for the user search.
#
# The baseFilter incorporates the user name entered for NNMi signin into the
# format needed for the distinguished name.
#
# The exact user name entered at the NNMi signin dialog is substituted for
# the expression "{0}" anywhere that it appears in the filter.
#
# A common value for baseFilter for OpenLDAP servers is:
# baseFilter=uid={0}
# A common value for baseFilter for Active Directory servers is:
# baseFilter=CN={0}
# or to use the Window NT 4.0 SAM-Account-Name:
# baseFilter=sAMAccountName={0}
#
baseFilter=uid={0}


#############################################################################
#
# You can verify the correctness of the above information in an LDAP client
# application, such as Microsoft Internet Explorer 7 or Mozilla Firefox 2.
#
# Enter an RFC 1959-compliant directory service URL with the above
# information, substituting a valid signin id. For instance, using the above
# values, and a signin of john.doe, you could test with a URL similar to:
# ldap://ldap.myco.com:389/uid=john.doe,ou=People,o=myco.com
# which is formed by concatenating the java.naming.provider.url, the
# baseFilter substituted with the signin name, a comma, and the baseCtxDN.
#
# If this URL times out, you probably have an incorrect directory service URL
# or port number.
#
# If you are using Active Directory (which does not allow anonymous binding),
# you can use an LDAP browsing program to verify your values are correct.
#
#############################################################################


#
# defaultRole:
#
# Optional. Use this parameter to specify a default role that applies to any
# directory service user who signs in to NNMi through LDAP. The value of this
# parameter applies regardless of where role mappings are stored (in the NNMi
# database or in the directory service). If a user is also a member of a group
# with an NNMi role attribute, NNMi uses the role with more privileges.
#
# Valid values are the NNMi roles: admin, level2, level1, guest, or client.
#
# If commented out, no default role is used, and the role mapping must
# be defined else the user will not be able to sign in to the NNMi console.
#
#defaultRole=guest


#############################################################################
#
# The remainder of the parameters in this file apply to customers who assign
# NNMi roles in the directory service.
#
# If you maintain NNMi role mapping in the NNMi database, stop here.
#
#############################################################################


#############################################################################
#
# After a user has been authenticated, NNMi queries the groups to which that
# user belongs to determine the NNMi roles that the user will have in NNMi.
# (When a user is assigned multiple roles, NNMi uses the role with more
# privileges.)
#
# The distinguished name that is passed to the directory service for
# identifying the groups to which a user belongs is the concatenation of the
# roleFilter value and the rolesCtxDN value.
#
# For example, if roleFilter is set to "member={1}", rolesCtxDN is set to
# "ou=Groups,o=myco.com", and the authenticated user distinguished name is
# "john.doe@myco.com", then the string passed to the directory service is:
# member=john.doe@myco.com,ou=Groups,o=myco.com
#
# All group distinguished names which have an attribute (uidAttributeID)
# that match the authenticated user will be used to assign the roles for
# the user. Any matching groups will use an attribute (roleAttributeID)
# to determine the role for the user.
#
#############################################################################


#
# rolesCtxDN:
#
# The group name search context, which is the fixed portion of the
# distinguished name for the user group search.
#
# This parameter must be set to enable directory service queries for NNMi
# role assignments through LDAP. If this parameter is not set in this file,
# LDAP queries for user roles are not attempted during user sign in.
#
# To disable directory service queries for NNMi role assignments through LDAP,
# comment out this parameter. The remaining values in this file will not be
# used.
#
# For a faster search, you can identify one or more directory service groups
# that contain NNMi roles. If the group names form a pattern, you can specify
# a wildcard. For example, if the directory service includes groups named
# "USERS-NNMi-administrators", "USERS-NNMi-level1Operators", and so forth,
# you could use a search context similar to:
# rolesCtxDN=cn=USERS-NNMi-*,ou=Groups,o=myco.com
# For an Active Directory server, this might be a value like:
# rolesCtxDN=CN=Users,DC=myco,DC=com
# which might be the same as baseCtxDN because Active Directory configurations
# sometime stores Groups and Users at the same level.
#
#rolesCtxDN=ou=Groups,o=myco.com


#
# roleFilter:
#
# The variable portion of the distinguished name for the user group search.
#
# The user name entered for signin is substituted for the expression {0}
# anywhere that it appears in the filter.
#
# The distinguished name of the authenticated user is substituted for the
# expression {1} anywhere that it appears in the filter.
#
# An example role filter that matches on the (short) user name entered for
# signin is: member={0}
#
# An example role filter that matches on the authenticated (full) user
# distinguished name is: member={1}
#
roleFilter=member={1}


#############################################################################
#
# You can verify the correctness of the group query by passing a URL
# similar to the following, and entering it into a web browser, unless
# your directory server does not allow anonymous authentication (as
# is the default case for Active Directory). An example is:
# ldap://ldap.myco.com:389/ou=Groups,o=myco.com??sub?(cn=SOME-PATTERN-*)
# which is formed by concatenating the java.naming.provider.url, the
# baseCtxDN, and an optional search context limiter.
#
# If you are using Active Directory, you can use an LDAP browsing program
# to verify your values are correct.
#
#############################################################################


#
# roleAttributeIsDN:
# roleAttributeID:
# roleNameAttributeID:
#
# roleAttributeIsDN is a flag indicating whether the user's role attribute
# contains the fully distinguished name of a role object, or the users's role
# attribute contains the role name.
# In certain directory schemas (for example, Microsoft Active Directory),
# role (group) attributes in the user object are stored as distinguished names
# to role objects instead of as simple names, in which case, this property
# should be set to roleAttributeIsDN=true
# In non-Active Directory cases, false is the correct value
# of roleAttributeIsDN.
#
#
# If roleAttributeIsDN=false, the role name is taken directly from the
# value of the user's role attribute (roleAttributeID).
# For non-Active Directory servers, it is recommended that a group be created
# with an additional attribute called "roleName" that contains a value of
# admin (for Administrator role), level2 (for Level 2 Operator role),
# level1 (for Level 1 Operator role), guest (for Guest role), or
# client (if required when using the NNMi SDK and integrations). In such
# a case, you would use
# roleAttributeID=roleName
# This attribute is the name of the attribute in the group, which is
# set to a different value for each NNMi role-defining group.
#
#
# If roleAttributeIsDN=true, the following definitions apply.
# roleAttributeID is the name of the attribute in the group that stores the NNMi role value that
# applies to the members of the directory server group. For Active Directory,
# this is usually:
# roleAttributeID=memberOf
# The role attribute (roleNameAttributeID) represents
# the distinguished name of a role object, and the role name is taken from the
# value of the "roleAttributeID" attribute of the corresponding group
# specified by roleNameAttributeID.
# This is also useful if you are unable to change the schema to add an attribute
# (such as roleName), and just want the name of the group to be the role. In
# that case, you could use roleNameAttributeID=name or
# roleNameAttributeID=CN to actually use the name of the group as the nnmi
# role. This implies that you created groups specifically called admin, level2,
# level1, guest or client.
#
# In some Active Directory implementations you cannot create a new attribute
# to store the NNMi role. Active Directory groups have an "info" attribute
# you can change (often named "Notes" in the Active Directory
# configuration). In this case you would set the "info" attribute
# in your Level 2 Group in Active Directory to "level2", and use
# roleNameAttributeID=info
#
roleAttributeIsDN=false
roleAttributeID=nnmiRole
#
# Active Directory instead uses roleAttributeIsDN=true
# In this case, the actual attribute to get the role is two hops
# away, using roleAttributeID to find the DN which actually contains
# the attribute.
#
#roleAttributeIsDN=true
#roleAttributeID=memberOf
#roleNameAttributeID=info


#############################################################################
#
# The following two attributes are used to enable Incident Assignment
#
#############################################################################


#
# userRoleFilterList:
#
# A semicolon-separated list of NNMi roles whose associated users can be
# assigned incidents in the NNMi console. The roles in this list apply only
# to directory service user names authenticated through LDAP.
# If this value is incorrect, sign in will find the correct user Role,
# but selecting an Incident and picking Actions -> Assign Incident... will
# bring up a dialog with no users.
#
# Valid values are the NNMi roles: admin, level2, level1, guest, or client.
#
userRoleFilterList=admin;level2;level1


#
# uidAttributeID:
#
# The name of the attribute in the group that stores the directory service user ID.
# The value of this attribute is used to locate the user's role. It is
# usually the attribute portion of roleFilter. This attribute is used for
# looking up the list of users for Incident assignment.
# If this value is incorrect, sign in will find the correct user Role,
# but selecting an Incident and picking Actions -> Assign Incident... will
# bring up a dialog with no users.
#
uidAttributeID=member

#############################################################################
#
# The following only needs to be modified if you are finding timeouts
# when accessing a distant directory server.
#
#############################################################################


#
# searchTimeLimit
#
# If you have a slow responding directory service, you may get errors like:
# javax.naming.TimeLimitExceededException: [LDAP: error code 3 - Timelimit Exceeded]
# in this case, you can increase the searchTimeLimit. This value is
# in milliseconds. The default value is 10000 (10 seconds)
#
#searchTimeLimit=10000