Developer forum

Hi Anders,

I see that the documentation for that method was changed to reflect the new behavior - I believe that the method was supposed to be obsoleted, though.

We will not change this behavior back in the future, and we will make further changes to Security/UserManagement in the next couple of releases. We have some legacy code that needs to be dusted a bit; we want to be able to distinguish between backend and frontend context to reduce the dependencies+responsibilities of these classes.

Fix for now: Use "Current(PagePermissionLevels.Frontend)" instead, if you're calling from frontend (though I cannot promise how long this will last, as that method is probably going to be obsoleted in the next year or so)

BR

Martin

Hi Martin,

Thanks for the respons. I know how to fix this, but I do not agree that this should be changed in a hotfix version. In the future I will appreciate breaking changes to be released in e.g. 9.3 instead between version 9.2.15 and 9.2.16 without any attention.

Please notice that the live integration project does not work any more as this relies on User.GetCurrentUser() as well.

Best regards, Anders

Hi Anders,

Hmm. I think the change was correct in what it was trying to achieve, but I can see what you mean about updating only to find that the methods have changed behavior. Since this was a mistake on our part, I will reintroduce this method the way it was, for next hotfix. It will be marked as obsolete with a compile-exception, though, so it wont be useable for recompiled code. This is because, the method is unneeded slow for frontend presentations - something we really want to change.

In the mean-time, can you make do with 9.2.15?

Also, could you please tell me which part of the live integration project that is broken? (I could find no active bugs for this, and I'd like to create one)

BR

Martin

Hi Martin,

An example of problems in live integration can be found here: https://www.screencast.com/t/zt5FuObBD, where User.GetCurrentUser() is used and will return null.

I have rewritten all the current application to use: User.GetCurrentExtranetUser(), so for now I have solved the problem, but we will have to rewrite all other 9.x version to same change.

Best regards, Anders

Hi Anders,

I see - I've taken a look at the Live Integration project, and rewritten it to use User.GetCurrentExtranetUser() as well. It will be released once it's been reviewed.

The reverted behavior for GetCurrentUser() will be part of the next hotfix OR will be part of Security 2.0.0 once this package is ready (technically a major change to revert back, although this was the only change).

TFS# 36226.

Anything I missed?

BR

Martin

Sounds great. This is not because I do not think the change makes sense, but just because it is a breaking change in a hotfix version :-)

Hi Anders,

Dynamicweb.Security 2.0.0 has now been released. It should fix your problem.

Alternatively, you can download the latest version of LiveIntegration to fix this with the broken version of security: http://doc.dynamicweb.com/releases-and-downloads/downloads

I hope this solves your issues. The next hotfix will include security 2.0.0.

BR

Martin

Hi Anders

The problem TFS#32226 "Change GetCurrentUser()" has now been fixed in Package "Security" version 2.0.0

You are able to find this update in the backend Package update section.

Also the correction are going to be part of the 9.3.17 release 

You are able to find this build in the download section:

http://doc.dynamicweb.com/releases-and-downloads/releases

Please contact Dynamicweb Support if you need any additional help regarding this.

Kind Regards
Dynamicweb Support
Kristian Kirkholt

We have the .17 release in place but it's still causing issues on existing sites. We get this:

Line 405: 'Dynamicweb.Security.UserManagement.User.GetCurrentUser()' is obsolete: 'Use Current() with PagePermissionLevels instead.'

You say: "It will be marked as obsolete with a compile-exception, though, so it wont be useable for recompiled code." That's normally a great idea but doesn't work for .cshtml templates as they are compiled more often.

While I am all for cleaning up an API, especially when slow performing methods are removed, I also don't think breaking existing sites in a dot release is a good idea. Should we make this a compilation warning in everything 9.2.* and obsolete it in 9.3?

Imar

Hi Imar

The package did receive a major version update - 2.0.0, so semantic version wise it is following guidelines. 9.2.* then uses that.

I've just committed the change to give a compile warning over an error on 2.1.1 of the security package.

BR Nicolai

From a package perspective I think that makes a lot of sense and I agree that's the right way. But when going from 9.2.16 to 9.2.17 I wouldn't expect such big / breaking changes, especially since they could be hidden further down in the site, making them less likely to be spotted by only light testing. We usually tell our customers that these dot releases are pretty much risk free because they only fix what's listed on the bug list. I would love for that statement to remain true as it makes a lot of things a lot easier.... ;-)

Imar