Hello 2sxc enthusiasts!
I developed a 2sxc application in a protected page. A group of users can read, add and modify the information in that 2sxc application. Since they can do some important actions but not administer the entire page, I gave the rights to "modify the module" (not certain it's the English terms...) to this group of users only for the 2sxc application developed. In my controller, the function attributes are:
[HttpPost]
[DnnModuleAuthorize (AccessLevel = SecurityAccessLevel.Edit)]
[ValidateAntiForgeryToken]
Everything works very well considering the code but giving the editing rights on the DNN module, it appears now the persona bar with this little pencil and no menus that ultimately is useless. This creates an overhead, slowing down the application without need.
I could set the rights to [DnnModuleAuthorize (AccessLevel = SecurityAccessLevel.Annonymous)] considering the presence of [ValidateAntiForgeryToken] and only base the security on the DNN page but is there a way to retain limited rights for the controller without having this persona bar?
Thanks for your advices!
As of 2sxc 9.30 there are new ways to set permissions, incl. at App-level. You could try to remove DNN edit permissions but set the app to editable. We haven't tried this scenario, but it could work.
Related
I'm doing a tutorial on communities, and after setting pages and themes, i wanted to add users. The access is made from the contact object.
I setup the community, but think i should have a link here
i setup the user of a contact like this:
User License = Customer Community
Profile = Customer Community User
Active = true
but when i try to log him in, i get: "Looks like this portal user is not a member"
I tried the same with another profile, a clone of the native Administrator profile, to which i added, in Profile Overview > App Permissions
Manage External Users = true
then, one by one, i activated all permissions, and still had that warning.
edit:
i'm using Classic
This is a developer licence
What am i missing?
The links disappeared because you killed off your own access to community (on Sysadmin, cloned profile etc). Do you remember editing this page? (sorry I had to censor some bits). If you removed System Administrator from the list of profiles - #fail.
If you can work with the new community and it's OK to have old one lying around - cool. If not - You might be able to resurrect it by exporting the community definition file, tweaking it and deploying back. I'm assuming you have some dev experience.
Prepare package.xml that contains
<types>
<members>*</members>
<name>Network</name>
</types>
Export the zip file (you don't neccessarily need developer tools, http://workbench.developerforce.com/ might be enough). Inspect the networks/YourCommunityName.network file. There should be a section similar to this
<networkMemberGroups>
<permissionSet>Censored1Access</permissionSet>
<permissionSet>Censored2Access</permissionSet>
<profile>Censored User</profile>
<profile>Admin</profile>
</networkMemberGroups>
Make sure "Admin" is on the list and deploy it back to org. It should give you access back and then you can add your customer community user's profile, permission set or whatever you plan to give them.
I understand Wagtail is a CMS. Per my test so far, only the admin has permission to publish an article/content. I checked out "puput" and a few others as listed here. I wonder is there a way to allow normal user registration, login, publishing? Something similar to Medium, where the normal user, or say the community, can contribute to the content generation.
I thought there might be a toggle or switch to enable this. But I didn't find it. I'm looking for a way that is either a package or a plugin or similar. Not coding from scratch. Ideally within Wagtail CMS, but other frameworks based on Django should also be fine.
Thanks.
Wagtail provides two user groups:
Editors: user within this group can create page and submit it to moderation
Moderators: user within this group can publish pages that have been submitted to moderation.
To update groups for a given user, go the the django admin interface with admin credentails, usually the url is your-domain/admin
Then go to Users under Authentication and Authorization category
Then get into the user you want to allow posting pages,
Scroll down until Permissions category and moove groups Editors and Moderators from Available groups to Chosen groups as follow:
Then save new settings.
I want to be able to make it so a registered user can only be logged into the DNN site from one device/browser at any one time.
I understand that the DNN core doesn't support sessions but does have a a users online table which is checked by the scheduler, however i have been unable to find anything available to use this method.
The main purpose is to stop a paid user from sharing their login details with multiple people and thereby diluting the potential revenue to the site. I would think this was not a unique use case and someone must have dealt with this previously.
Open to any and all ideas including commercial modules.
I suppose that you could create a custom login module, and reject logins from a user who appear as active in the UsersOnline table.
I haven't looked around to see what methods are available, but the old usersonline module should provide some hints.
I have two applications in my workspace, APP 1 and APP 2.
In my case, user will log in to APP 1. from there, i put a menu(or a link) to APP 2. however APP 2 requires authentication. So it will take me to a login page. i would like to eliminate that and get the current user's credentials on APP 1 and login to APP 2.
i'm looking for a simple straightforward method (but need to consider security) to login to APP 2.
what i could think of is apex_collection..i could store credentials n use it to create a login process for APP 2. however apex_collection is session based. eventhough i've set session for APP 2, it still wont read values from my apex_collection.
Does anyone have a suggestion or a solution?
All you need to do is use the same authentication scheme in both applications and set the cookie name attribute to the same value in both authentication schemes like this:
APEX will then use the same session across the two applications and the user will not have to log in again when they navigate from one to the other, provided of course that you pass the SESSION_ID in the URL.
A Few Comments on Default APEX Workspace Authentication Security
It may also be helpful to expand on an explanation of why the solution posted by #TonyAndrews works.
For any Apex Apps within the same workspace, if they use the default "APEX Application Authentication" method, they will consult the same authentication user list... so USER1 and its password is a valid login for any of the "neighboring" applications...
This may be a concern if you are hosting different clients or users that should not be intermingling with the other applications. You can also define user GROUPS in the same place as you set up each workspace user. Each application can have its own security filter that permits access by membership of BOTH user/password authentication AND membership in the appropriate access group.
Sharing workspaces may also be a problem because of the unique user name restriction of a single workspace. You can get around that by:
Defining different name-spaces for each application:
Email addresses are good: "someuser#sampledomain.com"
An app id prefix such as: SHOP_EDNA, SHOP_GARRETT, TC_KAREN, TC_MARLOWE, MY_BORIS etc.
Different name styles: first name only, first name + last initial, etc.
To keep things simple, you can always just spin up a brand new workspace: a warning however is that common user names like `ADMIN` are NOT the same between separate workspaces. There shouldn't be much concern however because apps or workspace users may have the same or different schema access privileges to the database back end.
A Word of Caution to Administrators and Developers:
When you go live with an application or multiple applications on a user-facing system, keep in mind the deployment destination (i.e., the workspace) and what else is sharing that workspace. There are some real situations where apps are not intended to be shared or accessed by other "inside" users. Be sure to read up and understand the security constraints and methods of using Default Apex Authentication security so that it's more than luck that protects your own production/live deployed applications.
I do have the similar requirement, linking from one application page to another.
Tried the above mentioned solution, but still asking to login to second application. My Apex ver is 5.0.3 and trying in same workspace.
Created new authentication schemes for each app with same cookie name and set them as current authentication. Scheme type are Application express accounts.
Setting the link as below from first app page to second.
href="http://servername:port/apex/f?p=224:2:&APP_SESSION"
Could anyone provide a solution, please?
Just an update on this.
I am currently using v21.2 and this is how I do it:
In both applications, go to Shared Components > Authentication Schemes > (Select your Auth Scheme);
Scroll down to Session Sharing and select 'Workspace Sharing';
In one of the applications (source), create a link (as a Navigation Bar List entry, for example) like f?p=173:1:&SESSION., where 173 is the target application ID and 1 is the target page.
After some research, I've found out that this feature (Session Sharing Type) is available since v18 of APEX.
I'd like to create visualforce page that inserts a record into salesforce account object. However, I expect some of the page users won't have salesforce accounts. Can they still access it? If not, what are the alternatives that can be used to visualforce page in this case? (Please don't consider Web to Lead Forms).
Thanks,
Yes, it's possible. Go read about Salesforce Sites. For a start:
http://wiki.developerforce.com/page/Websites
http://wiki.developerforce.com/page/An_Introduction_to_Force.com_Sites
(of course it's also possible to write that page in say Java/.NET/PHP and use integration via SOAP or REST to talk to Salesforce... but these 2 main links will keep the whole solution within SF so no need to need to learn new language, have extra maintenance effort etc)
Sites are VF pages that expose a bit of your company's data without need to log in. You can use them to input data too, just remember that in theory anybody could learn the link and spam you (not too different from web2lead, inbound email handlers etc). You specify security in a way similar to Profiles, the records will have "Created By = {site name} Guest User".
I don't think there's anything out of the box to restrict visibility, they're open to whole world. So if you would want something similar to login IP ranges (so only sales reps from your office's network can enter data) - you might have to write some logic in the controller.