Possible to read logged-on user's account name? - microsoft-metro

I'm developing my first Metro app using XAML. The app is for our company intranet use only. I have these questions -
Is it possible to retrieve the account name (domain\username) of the current logged in user? Do I need to use a WinRT component for this? I looked up Windows.Security.Authentication namespace and only Web and OnlineId are available.
I'm using the WebView control to navigate to a secure URL. If I open this URL in a browser, I do not get any prompts (since my machine is joined to the domain), but if I open the URL in a WebView, I get the username & password prompt. Is there a way to get rid of it?
Update - I was able to solve #2 question by enabling Enterprise Authentication in the Capabilities tab of the Package.appxmanifest file.

For No. 1:
Please use Windows.System.UserProfile.UserInformation class to get all relevant information
GetDisplayNameAsync()
GetDomainNameAsync()
GetPrincipleNameAsync()
e.g. to get the display name
if (UserInformation.NameAccessAllowed)
{
string player = await UserInformation.GetDisplayNameAsync();
}

Related

How to set AppClip invocation for URL with QueryParam?

I am trying to set the AppClip invocation for my App which is already released on app store.
I need an url such that it provides me a jobId e.g.: https://example.com/task?jobId=00001.
My use case is that I send the sms with the url https://example.com/task?jobId=00001 to the user, the user clicks on the url and the app gets started. Then for the other user I send the next url with corresponding jobId.
I did setup the AASA file for my domain (contains the JSON with "applinks" and "appclip" objects) which is valid, also the Domain status is valid on App Store Connect. There is a default experience set with title, subtitle, image and action. I also configured an advance experience for the url https://example.com/task.
However, my app clip doesn't get invoked if I access the url from either sms text or safari. :(
I do not have a web page for https://example.com/task therefore I haven't set up the meta data for this.
Is it possible to invoke the AppClip this way? It is really important for me that the URL is dynamic and I pass that jobId every time for each individual booking.
There s no much documentation and I already read at least twice Apple documentation about AppClip.
Because of this:
I do not have a web page for https://example.com/task therefore I haven't set up the meta data for this.
The answer to this:
Is it possible to invoke the AppClip this way?
Is no. Sorry, you need to own the domain you're working with, or at the very least have means to access its CNAME config (thus, be able to induce the owner of that domain to change the CNAME configs to what you want it to be, similar to what branch.io and AppsFlyer does with its users/clients).

visitor id mid is not consistent across domains when i login from app and then from moving from app to web

Experience cloud vistor id is used. App, web are using same adobe launch library. When I login into app url change and mid changes and then if I navigate from app to web responsive page mid is changed and I am not seeing any cross-domain pathing report from app to web ?
anything do I need to do with s.cookiedomainperiod or anything to make this work?
The Experience Cloud Visitor ID is not automatically carried over from the native mobile app to a (mobile) web page. The long story short is native apps don't really store data locally in the same way as web browsers, so there's no automatic ability to use the same local storage mechanism/source between the two.
In order to do this, you must add some code to the mobile app to append the mid value to the target URL, e.g. :
Android
String urlString = "http://www.example.com/index.php";
String urlStringWithVisitorData = Visitor.appendToURL(urlString);
Intent browserIntent = new Intent(Intent.ACTION_VIEW, Uri.parse(urlStringWithVisitorData));
startActivity(browserIntent);
iOS
NSURL *url = [NSURL URLWithString:#”http://www.example.com/index.php"];
NSURL *urlWithVisitorData = [ADBMobile visitorAppendToURL:url];
[[UIApplication sharedApplication] openURL:urlWithVisitorData];
If implemented properly, you should now see a adobe_mc= parameter appended to the target URL. Then on page view of the target page, if you have the Adobe Analytics javascript and Experience Cloud Visitor ID libraries implemented, they will automatically look for and use that value instead of generate a new value (should not require any config / coding on this end).
Update:
#Ramaiyavraghvendra you made a comment:
Hi #Crayon, mny thanks for your profound answer. I am sorry that i
missed to inform that this app is not native one but this is a SPA
app. so the implementation of entire app is also done through launch.
Could you pl help in this case then.
I'm not entirely sure I understand your issue. If you are NOT moving from a native mobile app to web page, and your mobile app is really a web based SPA that outputs Launch as regular javascript code throughout the entire app, then you shouldn't have to do anything; the Experience Cloud ID service should carry over the id from page to page.
So it sounds to me like perhaps your Experience Cloud Visitor ID and/or Adobe Analytics collection server settings are not configured correctly. the cookie domain period variables may be an issue, if logging in involves moving from say www.mysite.com to www.mysite.co.uk or similar, but shouldn't be a problem if the TLD has the same # of periods.
Or, the trackingServer and trackingServerSecure variables may not be configured properly. In practice, I usually do not set trackingServerSecure at all. These variables get kind of confusing and IMO buggy in different scenarios vs. what you are using, so I tend to use the "secure" value in the trackingServer field and leave the trackingServerSecure blank, and then Experience Cloud Visitor ID and Adobe Analytics will just use the secure version 100% of the time.
Or..it could be a number of other config variables not properly set. It's hard to say if any of this is off, without access to the app and Launch container.
Also you may want to check the response headers for your logged in pages. It may be that they are configured to reject certain existing non-https cookies or something else that effectively causes the existing cookies to be unreadable and make the Experience Cloud ID service generate a new ID and cookies.
Or.. maybe your app kind of is a native mobile app but using an http wrapper to pull in web pages, so it is basically a web browser but it is effectively like moving from one web browser to another (e.g. starting on www.site.com/pageA on Chrome, and then copy/pasting that URL over to Internet Explorer to view). So effectively, different cookie jar.
Launch (or DTM) + Experience Cloud ID (Javascript methods)
In cases such as the last 2 paragraphs, you have to decorate your target links the same as my original answer, but using the Launch + Experience Cloud ID Service javascript syntax:
_satellite.getVisitorId().appendVisitorIDsTo('[your url here]');
You write some code to get the target URL of the link. Then run it through this code to return the url with the parameters added to them, and then you update your link with the new URL.
Super generic example that just updates all links on the page. In practice, you should only do this for relevant link(s) the visitor is redirected to.
var urls = document.querySelectorAll('a');
for (var i = 0, l = urls.length; i < l; i++) {
if (urls[i].href) {
urls[i].href = _satellite.getVisitorId().appendVisitorIDsTo(urls[i].href);
}
}

Parse Signup Problems

So, I wanted to create a new social media app using Swift and Parse. When I go to the Parse site, and click on dashboard, it gives me a login screen. I don't have an account, so I click on the "I don't have a parse account" button. When I click on that, it just takes me back to the home page. I did manage to get the code and frameworks and stuff that I needed from the docs, but that didn't quite work. It gave me this for the initialize code:
let configuration = ParseClientConfiguration {
$0.applicationId = "YOUR_APP_ID"
$0.server = "http://YOUR_PARSE_SERVER:1337/parse"
}
In the tutorial I'm watching, rather than "YOUR_APP_ID" and "http://YOUR_PARSE_SERVER:1337/parse" it just had a bunch of letters and numbers, which I would assume are the app ID and Parse server. My guess is, that I need an account to get those. Would that be correct? And, does anyone know why I can't seem to get an account? Thanks.
Parse.com is shutting down, so that's why you are not allowed to create new accounts on the service. Check the blog post.
They open sourced a nodeJS implementation, which you should definitely check out at link, and here is an example to get you started. You can easily use the deploy buttons to host the server on services like Heroku, AWS, Azure, etc. You can also deploy a server locally, for testing purposes.
Although it's true that Parse is discontinuing early next year, you can still setup a new app if you want to use the service for a shorter term project. Replace your code with the following.
Parse.setApplicationId("YOUR-APP-ID", clientKey: "YOUR-CLIENT-ID")
You can find your App ID and Client ID in your app's settings > security & keys.
EDIT: You definitely need an account for this to work.

How to use new dropbox datastore API from chrome extension?

I'm trying to use a new dropbox datastore API with my chrome extension. If used as specified in tutoria, auth will fail with error 400:
Invalid redirect_uri: "chrome-extension://anzbpdekhbhcbekwmfazaophjcaabshl/chrome_oauth_receiver.html". It must exactly match one of the redirect URIs you've pre-configured for your app (including the path)
If i add this URL to my app profile at dropbox website, all works fine. But "anzbpdekhbhcbekwmfazaophjcaabshl" is a computer-unique value, it will be different for each extension installation for each user. Is it possible to somehow fix this or dropbox datastore API is intended to be used on static websites where redirect url is known?
Update 1
Extension ID is random for manual/non-public extension installation.
Update 2
I have found a way to make extension ID persistent: just pack it, generate a public key fro private .pem key and set this key's base-64 encoded value as 'key' in manifest.
Moving my comment to an answer (and see updates to the question for details):
I thought that the extension ID (the part right after chrome-extension://) was not user- or computer-specific and remained the same everywhere the Chrome extension is installed.
I'm successfully using the Datastore API from a Firefox extension. The trick is to attach the dropbox scripts to an actual webpage, not a local page. I have a blank page hosted on my server, and the extension opens that page and attached the necessary scripts. From there it redirects the user to the Dropbox authentication page.
Once the user has authenticated I open the same page in a "headless" tab using the page-worker API. (I don't know if Chrome extensions have the equivalent functionality)
The redirect URL has to be https so you'll need to get an SSL certificate for it to work.

Google Data/OAuth/AppEngine/Python - Properly Registering a Web Application

I'm creating a webapp with this combination of tools. I'm authenticating with App Engine in the following manner:
class googleLogin(webapp.RequestHandler):
def get(self):
callbackURL = 'http://%s/googleLoginCallback' % getHost()
#Create a client service
gdClient = gdata.docs.service.DocsService()
gdata.alt.appengine.run_on_appengine(gdClient)
gdClient.SetOAuthInputParameters(gdata.auth.OAuthSignatureMethod.HMAC_SHA1,
_GoogleConsumerKey,
consumer_secret=_GoogleConsumerSecret)
#Get a Request Token
requestToken = gdClient.FetchOAuthRequestToken(scopes=_GoogleDataScope,
extra_parameters={'xoauth_displayname': APP_NAME})
#Persist token secret
self.session = Session()
self.session[TOKENSECRETKEY] = requestToken.secret
gdClient.auto_set_current_token = True
gdClient.SetOAuthToken(requestToken)
authUrl = gdClient.GenerateOAuthAuthorizationURL(callback_url=callbackURL)
self.redirect(authUrl)
I authenticated my domain with Google at https://www.google.com/accounts/ManageDomain, entering a target URL and am using the given Consumer Key/Secret. For instance, if my domain was 'juno.appspot.com', I am using http://juno.appspot.com as the target url path prefix.
The process is working; however, Google presents this message to the user in a yellow security box:
"The application that directed you
here claims to be 'xxxxxx'. We are
unable to verify this claim as the
application runs on your computer, as
opposed to a website. We recommend
that you deny access unless you trust
the application."
I don't think I should be getting this error, since my server is getting the request token and creating the authorization URL. Does anyone have any insight on how to get rid of this warning?
Google's domain registration has an option to upload a certificate, but I shouldn't need to do that because I'm using OAuth with the HMAC_SHA1 signature method.
Also, not that it should matter, but I'm doing all this through a UIWebView on the iPhone. I'm specifically trying to do all authentication server-side to avoid exposing my Consumer Key/Secret.
Thank you for any tips :)
Solved.
The culprit is this line from above:
extra_parameters={'xoauth_displayname': APP_NAME})
Setting this value for a registered application intentionally triggers a warning to users, as indicated by the Google documentation:
xoauth_displayname:
(optional) String identifying the
application. This string is displayed
to end users on Google's authorization
confirmation page. For registered
applications, the value of this
parameter overrides the name set
during registration and also triggers
a message to the user that the
identity can't be verified. For
unregistered applications, this
parameter enables them to specify an
application name, In the case of
unregistered applications, if this
parameter is not set, Google
identifies the application using the
URL value of oauth_callback; if
neither parameter is set, Google uses
the string "anonymous".
Removing this line no longer allows me to use a 'nice' name in place of the domain, but it gets rid of that annoying yellow box :)
I'm not sure exactly where the issue may be in your code, but I've got a one page oauth/appengine/gdata example which may at least set you in the right direction. Have you tried to navigate to the site directly from the iPhone/desktop browser to see what message is delivered?
Hope it helps.
Alternatively, is it possibly to do with the user agent the UIWebView sets?