Our application is using MvcSiteMapProvider - 2.0.0.0 version. we would like to have HTTPS version of links listed in sitemap.xml even though it is a HTTP request.
Example:
If requested url is http://dummywebsitefortesting.com/sitemap.xml then all the <loc> tags should contain HTTPS version .i.e. , .....etc.
Is above requirement is possible in 2.0.0.0 version ? I tried to add protocol="https" but there is no luck. I tried to add hostName="www.website1.com" but there is no luck aswell.
Regards,
Kris
The Protocol and HostName properties were not added until version 4.6.1.
Prior to that, the only support for HTTPS was to use the Url property, which changes the node to make an absolute URL match, rather than using .NET routing (controller, action, etc.).
<mvcSiteMapNode title="Home" url="https://www.example.com"/>
However, I am pretty sure the Url property didn't function correctly before version 4.0.0.
See the related comments here and here about SSL support during development of 4.x.
Do note that MvcSiteMapProvider version 4.x supports .NET framework 3.5, 4.0, and 4.5 as well as MVC 2 - 5. Although upgrading is not quite seamless, it would probably be worth it to move on from such an old and buggy version of MvcSiteMapProvider IMHO, especially since you require functionality that didn't exist in version 2.x that now exists in the latest version.
Related
I moved to Bolt 4 (from Bolt 3.7) and would like to implement front-end user to give them access to private contents of the website. Previously, I used the extension BoltAuth/Auth, which worked like a charm.
Now in Bolt 4, there is no easy way like in Bolt 3.x to install an extension from the back-end page. I found out I could use composer to do so, but I run in the following problem:
> composer require "boltauth/auth:3.0.1"
[InvalidArgumentException]
Could not find a matching version of package boltauth/auth. Check the package
spelling, your version constraint and that the package is available in a stability
which matches your minimum-stability (stable).
Either I do something wrong, or the extension is not compatible with Bolt 4.1.
Could someone tell me if there is a way to make this extension work? Or alternatives for front-end user management?
EDIT: I'm now using the bolt/users extension as it can be used to add a ROLE_MEMBERS and let users login for the frontend.
Yes, unfortunately the architecture for plugins (mainly driven by the move from Silex to Symfony) changed completely between 3.x and 4.x and it's not really feasible to release new 4.x compatible versions.
So for now there won't likely be updates to BoltAuth. It may be worth joining the Slack community and seeing if any other developers are working on 4.x compatible solutions to the client login scenarios.
We are using .Net 4.5.2 and trying to add SameSite=Lax cookie attribute using URL rewrite rule. But getting Service Unavailable error. Does .Net 4.5.2 supports this?
In the documentation you can find that SameSite attribute is handled in .NET 4.7.2 and 4.8: link.
When you use web.config with lower version, VisualStudio underlines the SameSite attribute in Web.config and says SameSite is not allowed. There is also no SameSite and Secure properties for Cookie object until version 4.7.2.
I tried to run page with SameSite attributes with .NET 4.7.1 application and that worked, the app was able to run. I haven't checked if SameSite attribute in request is understood by server, but I know that SameSite attribute is present in Set-Cookie response header (.NET patch caused that).
You are probably missing .NET framework patch which adds such functionality. As I can see here, there are only patches for .NET from version 4.6 to 4.8, so unfortunately there is no patch for .NET 4.5.2.
Does .Net 4.5.2 supports this?
It does not.You first have to upgrade your .NET version to at least 4.6.
(My first answer on SO 🙂)
I'm setting up a site using Orchard CMS 1.10 that must support at least IE 7. The jQuery used in Orchard.Modules is the 2.x branch, which doesn't support older versions of IE.
I have tried putting the 1.x version in my theme and defining it like so:
manifest.DefineScript("jQuery").SetUrl("jquery-1.12.2.min.js", "jquery-1.12.2.js");
But everything that requires jQuery still uses the 2.x version from Orchard.Resources. It's not really feasible to to rename it something like "ThemeJQuery" because there are 3rd party modules that require jQuery and I don't want to modify them.
I managed to hack it by setting a version number on the declaration and making it higher than the one in Orchard.Resources, like so:
manifest.DefineScript("jQuery").SetUrl("jquery-1.12.2.min.js", "jquery-1.12.2.js").SetVersion("3.0");
This seems to work, but that fake version number is pretty hacky. Is there a better way to do this?
I want to use StandardKernel object in my IOC container for that I downloaded “ServiceStack.ContainerAdapter.Ninject”. this Ninject is dependency with ServiceStack.Common (≤ 3.9.59) but I AM using the latest version of ServiceStack version="4.0.36".
Can anyone suggest me how to use kernel in ServiceStack version="4.0.36".
IKernel kernel = new StandardKernel
According to the package's nuGet page , this package has a dependency on ServiceStack 3.9.59 and below. It doesn't appear to currently support the 4.x version of ServiceStack.
Looks like the code is hosted on github. You could contact the author and ask him about supporting 4.x or you could fork it, make it compatible with 4.x and then submit a pull request.
I have a XPage application where I use JavaMail in one of my managed beans. Currently I have added the jar-file C:\Programme\IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jarto the build-path of the manged bean. This works well. But now I want to use a newer version of JavaMail as the Domino server uses version 1.3 but I need version 1.4.x.
I have downloaded the new JavaMail jar-files from Oracle. In Domino Designer (version 9) I add this jar-file to the new design element "Code / Jars" and remove the old jar-files from the build path.
My managed bean is still compiling and running as desired, but if I check the version the bean is using it reports still version 1.3. To check the version number I use the debug property of JavaMail and it's reporting version 1.3 to the domino server console.
Is there a way to tell the domino server to use the jar-files in the application (i.e. the nsf) and not his own? Is there another approach to update the JavaMail version?
The reason I want to use a newer version of JavaMail is as follows: I want to read mails from an imap server with ssl. To avoid the problem of importing ssl-certificates I simply want to trust all hosts. This can be be done via MailSSLSocketFactory, but this is only available since version 1.4.2. Therefore I want to use a newer version of JavaMail.
Another reason I want to use a newer version is as follows: the method "getSortedMessages" of "IMAPFolder" is only available since version 1.4.4. (and so are some other features of JavaMail).
This may be a little too late for you... I think the right approach may be to include the jar file as an OSGi plugin.
I have spent some time to figure out how to do that - and recently succeeded :-) I have described the steps to perform to make this work in two articles. The first is about wrapping a JAR into a plug-in: http://www.dalsgaard-data.eu/blog/wrap-an-existing-jar-file-into-a-plug-in/ - the second is about deployment (and there is a link in the first one).
/John
You can solve the problem by creating an OSGi plug-in that supersedes the one that sports the JavaMail library: com.ibm.designer.lib.javamail.
In order to do that do the following:
Create an OSGi plugin whose id is com.ibm.designer.lib.javamail (Dalsgaard's tutorial on how to do it)
Set its version to a higher number than the one the Domino server is shipped with (to know the version type tell http osgi ss com.ibm.designer.lib.javamail). As of now using 9.0.1.qualifier should be fine
Deploy the plugin either through an update site or by directly copying it under the domino\workspace\applications\eclipse\plugins folder.
Restart the HTTP service. The higher version - the one you created - will now be used
I've got the same problem here, but found a solution. Be warned, this is not the best answer but it will work. Simply download the latest javamail jar here and rename the jar file to 'mail.jar'. Just replace the current file in IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jar with this file. Quit the http task and restart it. The code will now work with the latest version.