Well it looks like half the problem (the show-stopping half) is solved at least, I've replicated MgCryptographyUtil in .net (the relevant parts that do the encryption) and it seems to produce encrypted credentials that the MapGuide Server is happy with, and my unit tests seem to check out.
The packaging problem still remains though. There just doesn't seem to be a way to request encrypted MG_USER_CREDENTIALS as-is through the public resource service APIs. All requests for this resource data item will always return the decrypted username. The workaround for this is to have the Maestro packager auto-discard any MG_USER_CREDENTIALS during packaging (to prevent MgDecryptionExceptions when being loaded) and just require the user to re-supply the specific Feature Source credentials when loading this package somewhere else. That's an ugly workaround though. I really wish there was a better way, but I don't think there is a better way. - Jackie -- View this message in context: http://osgeo-org.1560.n6.nabble.com/You-should-probably-read-this-if-you-use-Maestro-tp4987345p4987524.html Sent from the MapGuide Users mailing list archive at Nabble.com. _______________________________________________ mapguide-users mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapguide-users
