Open Web Page at Login

I've seen this as well. Couple of thoughts-
1 - You might need to run the open command as the user and not as root. Your command above is going to use root's preferences, which may be why its not respecting the default browser setting as specified by the logged in user.

2 _ If opening the URL as the user still doesn't work, you'd need a more full fledged script that would pull the LSHandlerURLScheme setting for "http/s" from the user's com.apple.LaunchServices.plist file. Something like this will get you the bundle identifier for the default browser-

#!/bin/sh
currUser=$(/usr/bin/who | /usr/bin/awk '/console/{print $1}')
defaults read /Users/$currUser/Library/Preferences/com.apple.LaunchServices.plist | grep -B1 -m 1 "http" | awk '/LSHandlerRoleAll/{print $NF}' | sed -e 's/"//g;s/;//g'

org.mozilla.firefox

You should then be able to script it to open the URL with the application by specifying the bundle identifier

open http://ourintranet -b org.mozilla.firefox

Heh, I forgot you said it was a login policy, so true, $3 would work in that case.

Why not just make this a LaunchAgent instead if it's something so persistent?

Several reasons.

1. Since it is an intranet page, I can scope it to only run when connected to our network. That way a user is not bothered by the browser attempting to load a page when it can't be reached.

2. There are no files pushed to the client–An annoyed user could easily defeat a launch agent. We have a mandate that this run at every login.

3. We can change it at any time with extreme ease.

I'm attempting to do something similar, but am having very different results..

I've got a login script with simply:

$3 open http://www.google.com

As I understand it, that will end up running:

jsmith open http://www.google.com

This results in:

Script result: /private/tmp/open_website.sh: line 3: jsmith: command not found

Clearly, there is no 'jsmith' command...

How is this supposed to work?

Update:

Should have read a little more carefully.. instead of an external script, I should just be putting:

$3 open http://www.google.com

Into the 'Run command' section of the policy.

This almost works, I see Chrome popup immediately after logging in, but the window promptly disappears..

Hey Everyone,

Not sure if Firefox or Chrome support Applescript dictionaries, but this works for me on my Mac currently:

osascript -e 'tell app "Safari" to open location "http://jamfsoftware.com" '

So I decided to test it out:

$ osascript -e 'tell app "Firefox" to open location "http://jamfsoftware.com" '

Firefox works

osascript -e 'tell app "Google Chrome" to open location "http://jamfsoftware.com" '

Chrome works too, however, at first it failed for me because I didn't realize the process was called "Google Chrome," instead of just, "Chrome."

So, I think a simple Applescript will work. You could even save it as an app, and have a launch agent open it up upon users logging in, or have a policy trigger it. Remember that 'Run Commands,' from the advanced tab of a policy run as root, and run at the very end of a policy. So, you may have to do some Unix wizardry like this in the run command as the user, and please note I am not in my test lab right now so I cannot test this:

sudo -u $(/bin/ls -l /dev/console | /usr/bin/awk '{print $3}') osascript -e 'tell app "Safari" to open location "http://jamfsoftware.com" '

What sudo -u does, is executes the command as a specified user, and after the -u switch I ran a little command to see what user currently owns the /dev/console since there is no way for us to plan on who the current user could possibly be. I know that when Applescript runs as root it fails a lot, or at least I have seen it not work. Please test this out, and let everyone here know if this solution even works, or if you make my solution please share it with me as I would be curious to know.

Thanks,
Tom

Thanks for that approach Tom, but supplying that command under 'Run command' has the same result.. I see Chrome pop up and start to load the site, but then it disappears when the desktop appears.

Yup, I have the same results when running as a policy, but if I ran this as a login policy it works. You have to activate the app first to bring it into the foreground. Please test and post back if it works for you or not.

This is what I ran in the advanced tab, under the Run Command field:

sleep 10 ; osascript -e 'tell app "Safari" to activate' ; osascript -e 'tell app "Safari" to open location "http://jamfsoftware.com" '

I no longer have a test policy on our JSS for this, but back when I ran a few test scenarios for Kevin, I had something working that would open a set page in Safari (or default browser) and would not do the 'flash the page then disappear' act. Unfortunately while doing some JSS cleanup a few weeks back I got rid of it since it wasn't in use other than on one test box, so I can't recall exactly how I set it up. I think it was entirely in the Run Command field though and was using straight bash, not AppleScript.

The only thing I didn't care for was that it would open both the default page in a tab and the page I set in the policy in a separate tab. In other words, it would not replace the Home page,. just add a new tab, which I thought was rather annoying. But other than that it worked, every time I logged in on that Mac.

@Tom

Gave that a go, no dice.. It appears with that sequence the login process itself is delayed for 10 seconds, Safari then activates, loads up the site and then closes. This is all happening on the grey login screen. *Sometimes* the desktop will appear, then the browser will briefly flash in and out of existence.. Either way, it's not behaving!

jrtilson,

In my virtual test environment, my Computer Management Framework settings are set to background login actions under the Login/Logout Hooks tab. I am running a non managed local account on my 10.8 VM which I managed with my JSS test environment. Running Casper 8.7 on everything. I think if you background your login hooks it would perform better, and not try run before the user logs in. Test this out though, because maybe your environment would work best if login items happen at login, instead of being put in the background.

Thanks,
Tom

@Tom

Ah-ha! Backgrounding the login actions was the magic bullet. It's loading up AFTER the login process and the desktop has loaded. Seems to work with all the examples in this thread!

Thanks Tom!

Sorry to resurrect an old thread, but I have a similar request to open a webpage (using the default browser) at every login - the difference being they want to create an Active Directory group and scope it based on those users. So users in said AD group would login (Macs and PC's, but I only need to worry about Macs) and the webpage would open every time. Seems annoying, but not my call.

Any ideas on how I could accomplish this? If it were scoping machines, the above would be fine.

@boettchs][/url - As far as I know, login (and logout) policies can use LDAP user group scoping, but the policy must be set up to use Login or Logout as a trigger, in addition to any other triggers you may want. If the policy only uses something like the check in trigger, you can't add a User LDAP group to the scope.
This is all assuming of course that your JSS is connected to your LDAP environment, which I assume it is?

And I agree with you having a webpage open at every login seems rather annoying. I can't understand why some organizations/upper management actually think this is a good idea. We have a UX expert here on our team and something like this would through him into a rant over damaging the user experience. I think every company could use a User Experience professional to help avoid stuff like this.

EDIT: Just a quick clarification on what I actually meant on the LDAP stuff. LDAP User Groups can be added as a Limitation for the scope, not the actual Scope. Meaning, add in all managed Macs as the scope, then add in the LDAP User Group(s) as a limitation so it only runs for users that log in that are part of said groups. Just make sure Login is the only trigger.

@mm2270 - Hi Mike, yes, we're using LDAP. Login trigger would be the one we'd use based on what they said to me last night.

The reason they've given me (and they don't have to give me one) is that they are heavily promoting an artist (music industry) and this needs to be everyone's focus who is in the AD group.

My hiccup comes in figuring out the AD stuff and how to scope/script it.

Yeah, so you shouldn't have an issue then. As I mentioned, add any Macs in general you would expect this to run on as the primary scope, then add a specific LDAP User Group or groups as the Limitation. Along with the Login trigger, this should ensure it would only run for users within those groups as login. You'll see that LDAP Users and LDAP User Groups become available options (tabs) under Limitations as soon as you check the Login or Logout trigger boxes in the policy.

@mm2270 Cool, I was just creating a test policy like that and I'll see how it goes. Thanks for the pointers.

@boettchs, easier would be to create a LaunchAgent & a script.

At login the LaunchAgent would run the scrip for all users, will grab the username & then lookup the group membership.. If they are part of the needed group.. Then something like the below in AppleScript or OSAscript

open location "https://macmule.com

@bentoms, thank you. I've been using the script in the JSS using the AD group as the scope and it works great. Very simple and nothing needed to be uploaded and replicated. That to me gives it the edge as changes can be made on the fly - and I've already had to do that since they love it so much, they've made new AD groups and sites, etc. Thanks again for the ideas.

Hello all,
$3 open https://ourintrasite.com seems to open both the default browser and Safari.
Has anyone seen this while testing?

Thanks!