We are working on solution, that via injected javascript on Sharepoint Online site uses Outlook (O365)
REST API (client side) and injects entries to the calendar on Sharepoint subsite.
For that purpose, application on https://apps.dev.microsoft.com has been registered.
Overall, it’s working quite well, however, there is problem about Redirect URIs on the application itself.
As site collection contains many subsites with their own calendars, to make it work, we supposed to add
redirect URIs for all of the particular calendars, what may be difficult, as new sites will be created during site collection lifespan.
So basically what we would like to achieve, is to add for example “allowed domain” in the application,
that will allow redirections for the all of the subsites as well.
Is this even possible?
What is best practice?
Regards,
Pawel
Just redirect to a page in your app with all links you would like to include.
Also, keep in mind, using the api will apply security so the user will be able to see only authorized calendar for his identity, so you don't need to include static link that a user may not have access to.
Hope this helps.
Related
I would love to get advice on my current project structure idea. I have been searching regarding node.js multi domain packages but i am not sure if they will suit. I also would like to have a easy to manage apps eg. if i want to modify specific app, i have a feeling a single app will get really full and confusing to manage code wise? Basically i am building a website that will have:
Landing Page - www.maindomain.com
User Dashboard - members.maindomain.com
Admin Dashboard - admin.maindomain.com
Now each subdomain app can communicate to each other if they have the credidentials etc.
Would it be correct to create separate 3 Apps to handle each of the sites?
Is there any security concerns having this kind of 3 app setup?
Can account creation occur upon paypal payment?
Ideal flow would be User visits website on landing page and selects a paid package which in turn would direct to paypal. Upon payment user would be returned to website with account creation form, and said Package(order) would become an option on user dashboard.
Admin can pretty much view everything via admin dashboard pretty standard, setup promos etc.
Thanks for your help and advice.
I'm curious about the best/most efficient way to do this.
I've already set up my sharepoint 2010 site, and it is configured to use FBA. What i'd like to do is allow users to create their own accounts by filling out a form (the form will sit on a public sharepoint site, and filling it out creates a user in the membership database which is used for validation to enter the FBA sharepoint site).
I'm familiar with using the asp CreateWizard tool to build user accounts as part of a .Net web application, but I'm not sure on how to develop this as a webpart for use in a sharepoint site, as a webpart doesn't have the config file to store connection string and membership/role provider info.
Can this user creation form be put in a webpart and deployed to other sites, or is there another/better way to add this functionality to sharepoint (allowing users to register/create their own FBA accounts for access)?
There's nothing not much difference between SharePoint and regular ASP.Net for this.
The membership provider will need to be configured in the SharePoint web.config, including connection strings. However, it does not actually need to be used for login, so you can still create users in that membership provide from a different site.
I use a slightly different approach though - set up an anonymously accessible page in your site (in layouts is probably easiest, though a page within a site may be better for branding) and put controls on that page to create (and log in) a new user. You will need to call EnsureUser and possibly CreateUserProfile to give the new user access to anything, but aside from that it's all standard .net.
I have enabled anonymous users on the farm and on the entire site.
I also have Windows Authentication turned on.
Whenever an anonymous user attempts to view the site, they are prompted to log in.
And they get prompted to login on every single page they view.
I would like to allow users to log in via Windows Authentication, (perhaps through a special page), but anonymous users should not get prompted to put in their password ever.
Does that mean I need to switch to forms based authentication for the entire site, or is there an option in 2010 to somehow get Windows Authentication and allowing anonymous users to live harmoniously.
It could be because some of the file is not published. For ex, if master page, CSS stylesheet or any image is unpublished, it will prompt the user for login.
Make sure everything is published and it will work.
You need to see if it is anything on this path http://server/_catalogs/masterpage/Forms/AllItems.aspx
that it is not published.
You must publish everything
May be you missed some of the configuration steps .So i wish if you take a look to the following article
SP2010 Branding Tip #9 – Turn on Anonymous Access
Regards
I assume that you are using the Publishing Site Template for the public site and hence the default.aspx (the welcome page of all the subsites) is not published so you would need to start the approval workflow publish the pages and any other assets (master page, css, images etc)
You need to do some prepwork to set the site up using two web applications, both with different authentication methods. You can't run SharePoint effectively for Windows users and anonymous (or Forms based authentication) at the same time.
Essentialy:
Create your SharePoint site for internal users using Windows Authentication
Extend the site to a new site (using the same content database) but using anonymous or forms based authentication (whichever makes sense for you)
A MSDN article can be found here on this:
http://msdn.microsoft.com/en-us/library/ff648385.aspx
You can also read Andrew Connell's blog about this (he talks about Forms based authentication but you can do the same with anonymous access)
http://www.andrewconnell.com/blog/articles/HowToConfigPublishingSiteWithDualAuthProvidersAndAnonAccess.aspx
Basically you want dual authentication, Windows for one set of users and anonymous or FBA for another (and each access the site using a different URL)
Hope that helps.
Is it possible to create a site on demand? So in the response of an event, such as button click. I want users to be able to see one site (all users), but users with assigned to a certain group will see two sites.
Also, when would I want to create a seperate web application?
Thanks
Let's try to clear this up.
First, yes it's possible to create sites and webs programmatically, and in that sense you can do it in a click of a button event.
The second part of your question is not related to creating a sub site, it's related to permissions. Sub sites in SharePoint can have different permissions for different users.
So yes, users assigned to a certain group can see sub sites that others can't.
The third question can be answered by this Technet article.
Hope this helps.
Yes, you could use 2 seperate SharePoint web applications to provide access to a single site collection using different authentication providers. Enabling anonymous access for one web app and windows authentication for the other, you could use SharePoint authorisation to setup different permissions on site and pages for anonymous users as noted by Magnus.
In Moss 2007 you have the ability to set the target audience for each individual web part within a page. Is there a way to preview how the page will look to another user without logging in as that user? What I am looking for is a way for someone with full control/design permissions on a site to be able to preview how the site will be displayed to another user. Any suggestions?
I have a few test accounts that our IS department uses to preview pages, however we do not allow non-IS departamental staff to use those accounts. Those staff members only have access to their one account. So, if a user makes changes the target audience on a web part on one of their pages, right now they have no way to preview how the page will look to someone else other than asking someone else to login & watching over their shoulder. I can't give out the account information for the test accounts, nor can I create new test accounts.
Thanks!
Edit: I have the ability to preview. The problem is that other users with full control of a site can't preview the page. Here's a scenarios: In my school division each school has a site. The principal has full control of his school's site. On the landing page, he wants all the school announcements to be visible. However, some should only be visible to teaching staff, while others need to be visible to the students. He uses audience targetting but cannot preview to see at a glance that the targetting is correct. A lot of the users are not computer savy so things need to be as simple as possible. Also, that was just one scenario, there are other scenarios that are not divided by school. There are many users with full control of a site with different requirements - so it's not feasible to create test accounts for all scenarios.
First I don't think it is possible to have a preview feature if you are using NT security. Maybe it is something you can do with forms authentication but I never used it.
On that subject. I think when you are developing new features or integrating stuff on a MOSS/WSS server you need a little flexibility.
With what I see you have to following things you can do. It is surely more cost effective than developing a custom solution. I assume you are using NT Security.
User accounts : Ask your domain administrator to have dedicated user accounts to play with.
Virtual Machines : Ask to have some virual machines to be able to play with that server combined with tests accounts
Sandboxed environment : Ask your IT dept to create a sandboxed MOSS environment to have to possibility to replicate your actual MOSS environment and create custom user scenarios.
Edit: After re-reading the question I released that you want the users to be able to preview a page. I think you will need to look into writing a preview control that uses Impersonation to load the page. Not sure how feasible this is, but surely someone has created a preview feature. Sounds like a pretty common scenario to me.
Old Answer:
Could you not fire up a non MS browser such as Firefox, which will prompt for the username and password.
You can then just clear the session cookies to be prompted to log in as someone else.
This is the technique I used for an ASP.Net site that used authentication against the domain in a similar manner to SharePoint.
Alternatively, you can create a control/webpart that hooks into the audiences for the site and displays the audience membership to the user (maybe from the GetMembership call). This does not preview the site, but it will give your editors a heads up on who is in each audience. Something that will help them get the audiences correct.
We have made a similar webpart for security group membership.
I think there are two approaches you can take:
Do make use of test accounts to preview the pages. You can ease the "pain" to log in as another user by making use of the RUNAS command (http://technet.microsoft.com/en-us/library/bb490994.aspx). So it's possible to just create a shortcut on the desktop that opens a browser making use of another account's credentials. Only that browser instance will work with the test account.
Make a copy (or more copies) of the page that you want to preview, store it in a secured site (so it's only accessible for the principal for example), and tweak the Audience Targetting properties of the web parts on that page/pages.
For previewing target audiences only, the only way to do it is to create a target audience that runs based on a properties in the SSP User Profile Properties.
You can then have a control that allows the editor to change the value stored thier profile, re-compile the profiles and voila (for some description of voila) the user will have change thier audience targetting values to something else.
This would need quite a bit of coding and some thought put into the rules for the audience targetting.
At the end of the day, the most cost effective way is to push back to your infrastructure guys for an account solution that will allow you to have an "reader" account people can use for this function.